Reti di Calcolatori MODELLI I sistemi distribuiti sono sistemi nati dall’esigenza di soddisfare richieste distribuite distribuite con accessi eterogenei. Questi sistemi devono offrire caratteristiche solide di: Accessibilità e condivisione di risorse Affidabilità (dependability) per la tolleranza ai guasti. La dependability è comunque un attributo generico derivato dalla sintesi dei seguenti attributi di sistema: o Affidabilità (Reliability): capacità del sistema di funzionare ininterrottamente ininterrottamente senza guasti. Manutenibilità (Maintainability): tendenza del sistema a poter essere riparato; Disponibilità (Availability): capacità del sistema di continuare a funzionare correttamente anche in presenza di guasti. (è correlata con affidabilità e manutentibilità). manutentibilità). Performanza (Performability): capacità del sistema di offrire i servizi nei tempi prefissati; Incolumità (Safety): Capacità di non arrecare danni a cose, persone ed ambiente. Sicurezza (Security) capacità del sistema di fornire confidenzialità (impedire (impedire la fuga f uga di informazioni riservate permettendo accessi solo ad utenti autorizzati) ed integrità (accesso e modifica ai dati da parte degli utenti esclusivamente nelle modalità previste). o Le minacce che possono violare la dependability di un sistema sono classificate in: guasti, errori, disastri (naturali), attacchi (Intrusioni informatiche, vandalismo...) Uniformità in crescita e Scalabilità: indipendenza in prestazioni dal numero di nodi nel sistema. La scalabilità è un fattore che in ogni caso non può essere infinito. Infatti la scalabilità di un sistema si misura o
sempre all’interno di un range prefissato che ne assicura l’uniformità l’uniformità in prestazioni.
Apertura (openness): capacità di evolvere e operare seguendo naturali evoluzioni di specifiche.
Architetture MIMD (Multiple Instruction Multiple Data) è un'architettura un'architettura hardware parallela in cui diverse unità effettuano
diverse elaborazioni su dati diversi con comunicazione attraverso memoria condivisa. Architetture Software
Per una applicazione distribuita: distribuita: Analisi, sviluppo tramite algoritmo e sua codifica in linguaggi di programmazione. Mapping: Mapping: Configurazione per l’architettura di destinazione del sistema e gestione dell’allocazione delle risorse. Binding: è il processo tramite tramite cui viene effettuato effettuato il collegamento collegamento fra
una entità logiche e entità fisiche (o di sistema). Questo processo può avvenire in modo STATICO (collegato all’inizio e utilizzato) o DINAMICO (collegamento effettuato solo al momento del bisogno) Per i sistemi operativi esiste uno standard per le funzioni di accesso (API) e un modello architetturale. UNIX: Sistema operativo concentrato che fornisce un modello di conformità per l’accesso ai file, la concorrenza e la comunicazione con
primitive di sistema ( kernel) invocabili da diversi ambienti. In tutto questo è importante che si stabiliscano degli STANDARD (anche di fatto) affinchè tutti i sistemi siano uniformi e possano facilmente interagire. Modello dei processi
Processo autocontenuto che contiene tutto ciò che serve alla sua esecuzione. Non esiste condivisione di dati o variabili tra diversi processi. Esso contiene uno spazio di indirizzamento e uno spazio di esecuzione: parte di supporto per
Sono entità più leggere con limiti precisi di visibilità e barriere di condivisione. I processi leggeri sono attività che condividono visibilità tra di loro e sono caratterizzate da uno stato limitato e producono overhead limitato. Come contenitore unico di queste attività si considera in genere un processo pesante che fornisce la visibilità comune a tutti i thread. In Java i processi sono supportati come processi leggeri all’interno di un unico processo pesante (la JVM è un processo pesante che contiene i thread mappati in processi leggeri). In UNIX esistono diverse realizzazioni di processi leggeri ma nessuna di queste è diventata diventata standard. standard.
l’interazione con il sistema operativo e
per la comunicazione. I processi pesanti richiedono molte risorse (es in UNIX). Il cambiamento di contesto (passaggio da un processo all’altro) è un’operazione molto pesante con overhead soprattutto per la parte di sistema.
1
Il modello CLIENTE / SERVITORE
È un modello a due entità: Il cliente che effettua una richiesta e il servitore (o server) che offre il servizio e risponde. Il modello è SINCRONO (ci si aspetta una risposta) BLOCCANTE (attesa della risposta). Questo risolve il problema del rendezvous (per sincronizzare i processi comunicanti) con il server che rappresenta un processo sempre in attesa di richieste di servizio. Quindi ci si aspetta che il servitore ci sia e questo non viene attivato, ad esempio, alla ricezione ricezione del primo messaggio. Se il servitore non è attivo il supporto invia una indicazione di errore al cliente, in tutti gli altri casi il cliente aspetta la risposta. Il modello di comunicazione è 1 a molti (1 Server e N Clienti): Asimmetrico e dinamico perché il cliente conosce il servitore, solo al momento dell’invocazione e il servitore non conosce a priori i clienti possibili. Dinamico perché il binding (collegamento) tra cliente e servitore è dinamico (fatto solo quando il cliente fa una richiesta) Sincrono perché di prevede risposta dal servitore al cliente Bloccante perché il cliente aspetta la risposta da parte del servitore Il modello client/server è intrinsecamente molto utile perché è molto adatto alla interazione in un’ ambiente distribuito organizzato su molti nodi con risorse e servizi diversi da fornire. Il progetto del server è più complesso rispetto al progetto del cliente. Questo perché il server, oltre alla comunicazione, deve gestire l’accesso alle risorse di sistema considerando molteplici clienti e altri problemi come integrità dei dati, accessi concorrenti, autorizzazione di utenti, autorizzazione all’accesso e privacy delle informazioni. Inoltre il servizio deve essere sempre pronto alle eventuali richieste ->Server infinito o eterno (processo demone). Il Cliente, se non arriva la risposta dal server, effettua azioni compensative. Non aspetta per sempre (timeout predeterminato predeterminato che porta ad un’eccezione locale), può fare la richiesta ad un altro server o ripetere la richiesta (secondo politiche locali al cliente). Il server può non rispondere se è guasto (down o crashed) o lento e congestionato da richieste precedenti. Il modello implica un accoppiamento molto stretto tra le entità interagenti che devono essere presenti insieme per interagire. Anche se un’accoppiamento forte (strong coupling) come questo potrebbe essere troppo vincolante.
Il Server deve aspettare le richieste che sono messe in coda: prende una richiesta, la serve, serve, dà risposta e passa alla successiva –>Ciclo di lavoro sequenziale molto semplificante. Il server deve riconoscere una stessa richiesta e fare un solo servizio e fornire una sola risposta . Il coordinamento è facilitato dalla coda delle richieste e da un supporto dello stato delle richieste. Il cliente deve identificare in modo unico le richieste. richieste. Il server dopo avere fatto l’operazione e prodotto il risultato deve mantenerlo fino alla consegna richiesta dal cliente specifico.
Ci sono anche modellidiversi da quelli di default (sincrono bloccante): modelli verso l’asincronia (senza risposta). PULL : Si semplifica il progetto del servitore e il cliente decide quando fare la richiesta ripetuta, quanto spesso e quante volte identificando opportunamente le richieste. Il cliente ha s empre l’iniziativa. Il cliente si occupa del recupero del risultato con o senza attesa. PUSH: Il cliente fa la richiesta, una sola volta , si sblocca e può fare altro. Il server accoda la richiesta, arriva a fare il servizio e ha la responsabilità di consegna del risultato al cliente. Il modello push fa diventare il servercliente di ogni cliente. Carica di ulteriori compiti il servitore. Questo modello è molto usato per ampliare la fascia di utenza.
Modelli a delegazione
Possibilità Possibilità di delegare una funzionalità ad un’entità che opera al posto del responsabile e lo libera di un compito. Entità Proxy, Delegate, Agenti, Attori che svolgono una funzione al posto di qualcun altro. I proxy, solitamente, sono locali al cliente. Richiesta sincrona bloccante su un proxy -> Server libero. Questo permette di avere un’interazionesincrona non bloccante. La notifica avviene mediante eventi che si interpongono tra utenti e basso livello e permettono una gestione applicativa del sistema isolando i dettagli. Modello a Framework
Modello che prevede richieste sincrone a kernel. Il framework tende a rovesciare il controllo (per eventi di sistema). Il processo utente non aspetta, ma registra con una propria funzione. Esempio: in Windows nei processi è previsto un loop di attesa di eventi da smistare ai richiedenti. All’arrivo di un risultato questo viene portato al processo significativo. Le risposte dal framework al processo utente sono dette backcall o upcall (push del framework). Questi sono assimilabili assimilabili a eventi asincroni generati dal supporto che le applicazioni devono gestire.
2
Il modello CLIENTE / SERVITORE
È un modello a due entità: Il cliente che effettua una richiesta e il servitore (o server) che offre il servizio e risponde. Il modello è SINCRONO (ci si aspetta una risposta) BLOCCANTE (attesa della risposta). Questo risolve il problema del rendezvous (per sincronizzare i processi comunicanti) con il server che rappresenta un processo sempre in attesa di richieste di servizio. Quindi ci si aspetta che il servitore ci sia e questo non viene attivato, ad esempio, alla ricezione ricezione del primo messaggio. Se il servitore non è attivo il supporto invia una indicazione di errore al cliente, in tutti gli altri casi il cliente aspetta la risposta. Il modello di comunicazione è 1 a molti (1 Server e N Clienti): Asimmetrico e dinamico perché il cliente conosce il servitore, solo al momento dell’invocazione e il servitore non conosce a priori i clienti possibili. Dinamico perché il binding (collegamento) tra cliente e servitore è dinamico (fatto solo quando il cliente fa una richiesta) Sincrono perché di prevede risposta dal servitore al cliente Bloccante perché il cliente aspetta la risposta da parte del servitore Il modello client/server è intrinsecamente molto utile perché è molto adatto alla interazione in un’ ambiente distribuito organizzato su molti nodi con risorse e servizi diversi da fornire. Il progetto del server è più complesso rispetto al progetto del cliente. Questo perché il server, oltre alla comunicazione, deve gestire l’accesso alle risorse di sistema considerando molteplici clienti e altri problemi come integrità dei dati, accessi concorrenti, autorizzazione di utenti, autorizzazione all’accesso e privacy delle informazioni. Inoltre il servizio deve essere sempre pronto alle eventuali richieste ->Server infinito o eterno (processo demone). Il Cliente, se non arriva la risposta dal server, effettua azioni compensative. Non aspetta per sempre (timeout predeterminato predeterminato che porta ad un’eccezione locale), può fare la richiesta ad un altro server o ripetere la richiesta (secondo politiche locali al cliente). Il server può non rispondere se è guasto (down o crashed) o lento e congestionato da richieste precedenti. Il modello implica un accoppiamento molto stretto tra le entità interagenti che devono essere presenti insieme per interagire. Anche se un’accoppiamento forte (strong coupling) come questo potrebbe essere troppo vincolante.
Il Server deve aspettare le richieste che sono messe in coda: prende una richiesta, la serve, serve, dà risposta e passa alla successiva –>Ciclo di lavoro sequenziale molto semplificante. Il server deve riconoscere una stessa richiesta e fare un solo servizio e fornire una sola risposta . Il coordinamento è facilitato dalla coda delle richieste e da un supporto dello stato delle richieste. Il cliente deve identificare in modo unico le richieste. richieste. Il server dopo avere fatto l’operazione e prodotto il risultato deve mantenerlo fino alla consegna richiesta dal cliente specifico.
Ci sono anche modellidiversi da quelli di default (sincrono bloccante): modelli verso l’asincronia (senza risposta). PULL : Si semplifica il progetto del servitore e il cliente decide quando fare la richiesta ripetuta, quanto spesso e quante volte identificando opportunamente le richieste. Il cliente ha s empre l’iniziativa. Il cliente si occupa del recupero del risultato con o senza attesa. PUSH: Il cliente fa la richiesta, una sola volta , si sblocca e può fare altro. Il server accoda la richiesta, arriva a fare il servizio e ha la responsabilità di consegna del risultato al cliente. Il modello push fa diventare il servercliente di ogni cliente. Carica di ulteriori compiti il servitore. Questo modello è molto usato per ampliare la fascia di utenza.
Modelli a delegazione
Possibilità Possibilità di delegare una funzionalità ad un’entità che opera al posto del responsabile e lo libera di un compito. Entità Proxy, Delegate, Agenti, Attori che svolgono una funzione al posto di qualcun altro. I proxy, solitamente, sono locali al cliente. Richiesta sincrona bloccante su un proxy -> Server libero. Questo permette di avere un’interazionesincrona non bloccante. La notifica avviene mediante eventi che si interpongono tra utenti e basso livello e permettono una gestione applicativa del sistema isolando i dettagli. Modello a Framework
Modello che prevede richieste sincrone a kernel. Il framework tende a rovesciare il controllo (per eventi di sistema). Il processo utente non aspetta, ma registra con una propria funzione. Esempio: in Windows nei processi è previsto un loop di attesa di eventi da smistare ai richiedenti. All’arrivo di un risultato questo viene portato al processo significativo. Le risposte dal framework al processo utente sono dette backcall o upcall (push del framework). Questi sono assimilabili assimilabili a eventi asincroni generati dal supporto che le applicazioni devono gestire.
2
Modello Publish/Subscribe
Modello molti a molti. In caso di iniziativa mista, e necessario che gli interessati manifestino interesse alle informazioni attraverso una registrazione (subscribe) e poi si ricevono tutte le informazioni generate (publish). Rappresenta un modello push a tre untità: 1. Gli utenti (subscriber o consumatori) che si registrano come interesse (subscribe). 2. Un gestore (servitore di notifica) che registra gli interessi, riceve la notizia degli eventi generati e notifica ai consumatori sottoscrittori. 3. I produttori che generano gli eventi e fanno publish.
Modello ad eventi
Il modello ad eventi è asincrono e fortemente disaccoppiato: prevede di avere molti produttori, molti consumatori, e ad assumere l’esistenza di un supporto. In questo modo si gestisce l’invio di messaggi disaccoppiando gli interessati. interessati.
I produttori segnalano. I consumatori ricevono dopo sottoscrizione (pub/sub), il gestore degli eventi segnala l’occorrenza degli eventi e i relativi messaggi agli interessati sottoscrittori (push dei messaggi).
Confronto C/S con Scambio di messaggi
Client/Server o
o o
Modello a accoppiamento forte (strong coupling) che implica la compresenza di entrambe le entità interagenti. Meccanismo molto adatto per comunicazioni di alto livello e semplici per uso applicativo e utente. Non così flessibili per situazioni diverse e specifiche (impossibilità (impossibilità di MX e BX)
Eventi, PUB/SUB e Scambio di messaggi Sender/receiver o
o o
o
Modello a scarso (minimo) accoppiamento (loosecoupling) che non impone la compresenza delle entità interagenti. Molto flessibile, primitivo ed espressivo, ma non facile da usare. Molto a basso livello (e adatto per ogni possibile uso del sistema), si permettono molti diversi diversi usi eterogenei del sistema. Supporto ad ogni possibile tipo di comunicazione (anche BX e MX)
Connessione nel C/S
Nella interazione C/S si considerano due tipi principali riguardo all’insieme delle richieste: Interazione connection-oriented(con connessione) Si stabilisce un canale di comunicazione virtuale prima di iniziare lo scambio di dati o o Tutti i messaggi seguono la stessa strada (route) per la coppia mittente destinatario decise staticamente e impegnano risorse intermedie. Alcuni modelli a connessione (TCP basato su IP) non impegnano risorse intermedie intermedie ma solo mittente o destinatario Interazione connectionless (senza connessione) Senza connessione virtuale, ma semplice scambio di messaggi isolati tra loro o o I messaggi possono seguire strade diverse decise dinamicamente e non impegnano risorse intermedie. La scelta dipende dal tipo di applicazione e anche da vincoli imposti dal livello di comunicazione sottostante. Per esempio, in internet il livello di trasporto prevede protocolli TCP e UDP basati su IP (tipicamente connectionless e best effort):
UDP senza connessione, connessione, non reliable e non preserva l’ordine dei messaggi
TCP con connessione, reliable (affidabile) e preserva l’ordine di invio dei messaggi e a maggiore affidabilità
3
Visibilità
Nella comunicazione è importante se si possa essere in visibilità di tutti i potenziali partecipanti (scalabilità). Modelli locali(o ristretti) prevedono limiti alla interazione o Operazioni Scalabili poco dipendenti dal diametro del sistema Modelli globali Non impongono restrizioni alle interazioni Operazioni non scalabili dipendenti dal diametro del sistema o Si va verso la località, vincoli, domini per ottenere scalabilità.
Stato In una interazione C/S un aspetto centrale è lo stato delle richieste contro l’autocontenimento delle richieste. Lo stato dell’interazione viene usualmente memorizzato nel Server che può essere
Stateless non tiene traccia dello stato: ogni messaggio è completamente indipendente dagli altri e autocontenuto. o o
o o
È più leggero e più affidabile in presenza di malfunzionamenti (soprattutto causati dalla rete) Fornisce API più complete e complesse perché, essendo i messaggi auto contenuti, c’è bisogno di essere più specifici Porta ad un progetto del cliente più complesso ma semplificano il progetto del Server Una interazione stateless è sensata e possibile SOLO se il protocollo è progettato per operazioni idempotenti: operazioni che tendono a produrre lo stesso risultato anche se ripetute (a meno che non cambi lo stato del server stesso)
Stateful si mantiene lo stato dell’interazione tra chi interagisce un messaggio con l’operazione conseguente può dipendere da quelli precedenti o o o
o
o
Garantisce efficienza: dimensioni messaggi più contenute e migliore velocità di risposta del Server API più semplici Un Server stateful deve sicuramente presentare un impegno di risorse ulteriore per identificare la sessione del Client e tenerne traccia per le interazioni future. Il vantaggio è di avere minore costo delle operazioni in termini di banda impegnata, sicurezza e garanzie di ripristino in caso di problemi dei clienti. Lo stato si distingue in: Stato permanente mantenuto per sempre Stato soft o a tempo
Progetto del Servitore Modelli di servizio
Servitore sequenziale o iterativo si possono introdurre ritardi se
la coda di richieste cresce o Serve una richiesta alla volta e itera il servizio Per limitare overhead: limitare la lunghezza della coda o (sveltendo il servizio), rifiutare le richieste a coda piena (rifiutando il servizio)
Servitore concorrente capacità di servire più richieste insieme sfruttando i tempi morti o o
Serve molte richieste insieme e può ottimizzare l’uso della risorsa processore eliminando i tempi di idle . Un servitore concorrente può essere multiprocesso un processo server che si occupa della coda delle richieste e genera i processi figli –> uno per ogni servizio) monoprocesso unico processo server si divide tra il servizio della coda delle richieste e le operazioni vere e proprie.
Servitore con stato interazione il servitore tiene traccia dell’interazione con i clienti
Servitore senza stato interazione il servitore “dimentica” le ric hieste appena le ha eseguite
Servitore con connessione le richieste arrivano in ordine di emissione del cliente
Servitore senza connessione ogni richiesta arriva in modo indipendente (senza ordine)
4
Progetto del C/S Schema di base: asimmetrico, sincrono, bloccante
Progetto dei Clienti più semplice. Spesso sono sequenziali, potrebbero essere anche concorrenti.
Progetto dei Servitori più complesso per la operazione svolta dal server stesso e dai molteplici clienti (molti a 1). Un
server deve essere sempre presente al momento delle richieste dei clienti. Processi demoni che rimangono attivi per tutta la durata del sistema. Demoni -> eseguono un ciclo infinito di attesa di richiesta e esecuzione delle stesse (sequenziali ma spesso concorrenti). In Java thread Daemon rispetto a un thread comune (user) esegue per tutta la durata di una sessione della JVM terminandone l’esecuzione solo quando termina l’ultimo thread user Modello ad agenti multipli
Schema in cui i servizi sono forniti dal coordinamento di più servitori detti agenti che forniscono un servizio globale unico . Gli agenti forniscono il servizio coordinato e possono partizionare le capacità di servizio o replicare le funzionalità del servizio , tutto in modo trasparente al cliente. Vi possono esser anche modelli a livelli multipli per la divisione dei compiti: Clienti che interagiscono con Agenti Agenti, anche paralleli, capaci di coordinarsi Server di operazione paralleli, replicati e coordinati Con necessità di protocolli di coordinamento, sincronizzazione, rilevazione e tolleranza ai guasti.
Sistemi di Nomi
Nella relazione C/S, il cliente deve riferire il servitore. Questo è reso possibile dal nome del servitore nel cliente. I clienti possono usare molte forme di nomi diversi:
nomeGestore.nomeServizio
123:123456 (non trasparente)
nomeServizio
stampa (trasparente) (binding dinamico)
Esistono nomi Trasparenti e Non Trasparenti alla allocazione. La trasparenza non lega il nome a dettagli di basso livello . I nomi, ossia i riferimenti ad altre entità, sono distribuiti nel codice dei clienti, degli utilizzatori, delle librerie ecc. e se ne deve garantire la consistenza. Per la risoluzione dei riferimenti e la qualifica dei nomi si effettua un’operazione di binding: Statico i riferimenti sono risolti prima dell’esecuzione. Tipico di sistemi concentrati, si risolve tutto staticamente e non si necessita di un servizio di nomi o
considerata l’invarianza dei nomi e della allocazione delle entità
Non è consentito cambiare alcuna allocazione (problemi) Dinamico i riferimenti sono risolti solo al momento del bisogno e durante l’esecuzione. Tipico in sistemi distribuiti in cui le risorse sono dinamiche e non prevedibili staticamente. o o
o
I sistemi di nomi sono presenti durante l’esecuzione per effettuare il binding.
o
Le entità non sono staticamente fissate
Nasce la necessità di un servizio di nomi (name server -> Agente) che mantiene e risolve i nomi e che fornisce il servizio durante la esecuzione coordinandosi con i gestori della allocazione o Tipicamente si usano delle tabelle di allocazione controllare da opportuni gestori di nomi I nomi possono essere a loro volta non trasparenti (dipendenti dalla locazione) o trasparenti (non dipendenti dalla locazione). I nomi trasparenti permettono ad un entità di cambiare allocazione senza cambiare nome. o
In sistemi aperti tipicamente si devono introdurre molteplici gestori di nomi distinti e coordinarne l’esecuzione. Partizionamento dei gestori ciascuno responsabile di una sola parte dei riferimenti e località. Replicazione dei gestori ciascuno responsabile con altri di una parte (partizione) dei riferimenti e coordinamento.
I gestori sono spesso organizzati a livelli: un gestore generale che coordina gestori di più basso livello in molti livelli con località di informazioni. Questo li rende più efficienti per la “località” e meno efficienti per sistemi più “lontani” ma è un prezzo che si è disposti a pagare a vantaggio dell’efficienza dell’intero sistema.
5
DNS (Domain Name System) Insieme di gestori di tabella di nomi logici host e indirizzi IP corrispondenti. DNS organizza i nomi logici in una gerarchia (albero DNS) intesa come gerarchia di domini logici e centri di servizio. La
corrispondenza tra nomi logici e indirizzi fisici avviene dinamicamente tramite un servizio di nomi che risponde (dinamicamente) alle richieste. Ogni nome è diviso in parti che rappresentano domini diversi (server), i domini di base (di primo livello) sono ad esempio: IT, COM, EDU, GOV ecc.
Es. deis33.deis.unibo.it Riferisce ad un dominio nazionale italiano. È a 4 livelli. Il numero di livelli è dinamico (non standardizzato). Ogni nome permette dei mappaggi logici propri. I singoli nomi sono case sensitive e al massimo 63 caratteri per dominio. Nome completo massimo 255 caratteri. I domini sono del tutto logici e non sono collegati in nessun modo alle reti fisiche o alle organizzazioni di rete. Ogni dominio può essere usato in modo relativo o assoluto. Ogni dominio relativo fa riferimento al dominio che lo contiene. Architettura del DNS
Ogni nome di dominio corrisponde ad un server di responsabilità. I domini sono organizzati su responsabilità primaria di un server (detto ZONA –> 1 o più server). Ogni zona riconosce una autorità , ossia un server che fornisce le corrette corrispondenze e garantisce caratteristiche specifiche come, ad esempio, replicazione. I diversi servitori che gestiscono domini suddivisi on zone possono a loro volta delegare la gestione ad altri server con sottodomini e servitori sottostanti. Le richieste sono smistate dal sistema in modo opportuno. Ogni richiesta di utente viene fatta al servizio di nomi in modo indiretto tramite un agente specifico (Name Resolver) per la gestione dei nomi della località. (Caching) I diversi server DNS sono organizzati per ottenere diversi requisiti: affidabilità, efficienza e località. Ogni dominio ha un Name Resolver e domain name server locali (un o più in replicazione) e usa estensivamente cache per conoscenze pregresse. Il resolver fornisce la risposta o perché conosce già la corrispondenza (in cache) o la trova attraverso una richiesta C/S ad un name server. I DNS name server sono organizzati come agenti per ottenere informazioni reciprocamente (dalla più corretta autorità) e poter fornire a loro volta risposte consultando le rispettive tabelle DNS L’organizzazione ad albero consente di muoversi tra i DNS con le richieste necessarie fino a raggiungere il dominio di autorità. I diversi DNS sfruttano la replicazione per fornire la risposta anche in cado di problemi (Affidabilità). Clienti e Resolver (anche fra diversi DNS) fanno richieste usando il protocollo UDP (porte 53). In caso di messaggi troppo lunghi (>64k) allora si usa TCP. Viene usato TCP per l’aggiornamento dei secondari. Query DNS:
Ricorsiva o o o
Richiede al resolver (o DNS) che fornisca la risposta (chiedendo ad altri) o segnali un errore. Si prevede una catena di server request/reply Il resolver o DNS rimane impegnato fino a risposta o timeout
Iterativa o
o o
Richiede al resolver (o DNS) che fornisca la risposta o il migliore suggerimento come riferimento al miglior DNS server Si prevede una sequenza di server request/reply a server Risponde con un riferimento al gestore più vicino che possa ragionevolmente rispondere
6
OSI Open System Interconnection stabilisce standard di comunicazione tra sistemi aperti con l’obiettivo di realizzare interoperabilità tra
sistemi eterogenei. È uno standard “di comitato”, di gestione, non operativo: non fornisce realizzazioni. Gestione dei sistemi: definisce come si possono controllare, coordinare, monitorare sistemi interconnessi eterogenei. Quindi non definire come avviene la comunicazione ma come gestire il sistema interconnesso. È uno standard: organizzato a livelli precisi, ad oggetti, come scenario generale di soluzione, senza legami con le realizzazioni. Livelli Ci sono 7 livelli. Ogni sistema a livelli, come OSI, si basa sul principio di separazione dei compiti (delega) e della trasparenza della realizzazione (astrazione).
Ogni livello fornisce al livello superiore un’interfaccia o servizio (visione verticale): Definizione del servizio: definizione astratta dei servizi del livello corrente disponibili al livello immediatamente superiore. Ogni livello ha l’obiettivo di comunicare con il livello corrispondente e di gestirlo. Questo viene realizzato tramite un protocollo (visione orizzontale): Specifica del protocollo : specifica dettagliata di come il livello fornisce il servizio tramite scambio di dati ed informazioni tra le due realizzazioni dei sistemi comunicanti. OSI introduce un sistema di nomi molto preciso per i servizi e i protocolli.
SAP Service Access Point o (N)-SAP: è una interfaccia logica tra una (N-1)-entity ed una (N)-entity. Quando un livello ha bisogno di
comunicare con un altro il SAP si occupa di gestire le richieste tra i livelli . Quindi per chiedere qualcosa ad un particolare livello si deve far riferimento alla SAP relativa al livello corrispondente. Esempio: se voglio chiedere qualcosa al livello di trasporto (T, Layer 4) devo chiederlo alla SAP corrispondente (T-SAP) che fornirà la risposta. Ogni SAP ha un nome unico che la identifica. Per identificare un’entità (es di Layer 6) si dovrebbero nominare tutti i SAP di ogni livello (fino all’1). In questo caso ci si ferma ai nomi di rete (Layer 3 – Network). Una entità (pari) viene quindi identificato come SAP di rete e con la sequenza di stack dei nomi delle entità per identificare il livello superiore (IP, porte, socket, processo ecc.) –> Si specifica in modo non ambiguo ogni partecipante.
Dimostrazione del fatto che OSI non è legato alle implementazioni. L’organizzazione a SAP è completamente astratta e potrebbe essere applicata alla modellazione di sistemi molto diversi.
Comunicazione In genere per una comunicazione si hanno un mittente, un destinatario e degli intermediari. In OSI gli intermediari sono fissi e devono partecipare alla comunicazione intesa come risorse per mantenerla. Standardizzazione dei messaggi -> descrizione i messaggi che permettono: Chiedere il servizio SDU (Service Data Unit o Interface Data Unit, IDU) Specificare il protocollo PDU (Protocol Data Unit) Le informazioni che vanno verso il basso sono incapsulate e devono poi essere trattate dal protocollo. L’interfaccia con il livello sottostante IDU contiene anche la parte di specifica di protocollo: ICI (Interface Control Information) coordina operazioni, determinando il protocollo e definendo il PCI (Protocol Control Information). PDU fornito dal protocollo diventa SDU (Service e Interface) per il livello sottostante.
1
Su iniziativa del mittente ogni livello introduce le proprie esigenze specifiche (header -> PDU) a quelle del dato e le passa al SAP sottostante, fino al livello fisico, dopo il quale, dalla parte del destinatario si ricomincia a risalire fino all’Application corrispondente rimuovendo man mano gli header ad ogni livello di competenza. C’è molto overhead relativo all’inclusione di tutti questi dati aggiuntivi utili a realizzare e gestire la comunicazione. Livello di intrusione di un protocollo = quanto “snelli” sono gli header.
Modalità
Connectionless: Ogni unità di dati è trasferita in modo indipendente dalle altre unità ed è autocontenuta (senza ordine)
Nessuna qualità di servizio. Lo scambio di informazioni tra due pari avviene senza storia e senza concetto di negoziazione. Soluzione a basso costo
Adatta per dati occasionali e senza qualità della comunicazione. Costo limitato ma scarse garanzie. Connection-Oriented: Soluzione privilegiata da OSI. Si stabilisce una connessione tra entità pari che devono comunicare, con caratteristiche della connessione negoziate nella fase iniziale. Oltre a mittente e destinatario, quindi, si interpone una terza entità che è la connessione. La comunicazione avviene tutta nell’ambito di una sessione di comunicazione che è eretta dalla connessione. Negoziazione iniziale per stabilire regole ben precise sulla comunicazione per la qualità. o Comunicazione in tre fasi: Apertura, Trasferimento dati, Chiusura Il servizio di un livello deve fornire anche opportune funzionalità per le tre fasi con qualità di servizio. o In OSI –> Garanzia piena per la connessione: OSI garantisce che gli intermediari ci sono e ognuno di essi garantisce banda e QoS. La comunicazione può avere luogo in modo bidirezionale sulla connessione. o o Su una connessione costi più elevati ma maggiori garanzie o
Primitive Le due entità pari cooperano per implementare le funzionalità del livello cui appartengono. Primitive base: DATA per trasmettere contenuto, CONNECT, DISCONNECT per aprire e chiudere una connessione. Quattro possibili forme per una primitiva: 1. Request il service user richiede un servizio (una azione) 2. Indication il service provider indica al service user che è stato richiesto un servizio (segnalazione di evento) 3. Response il service user specifica la risposta alla richiesta di servizio (una azione) 4. Confirm il service provider segnala la risposta alla richiesta di servizio (segnalazione di evento)
Asincrona Bloccante:
Mittente invia con una Request, arriva al destinatario con una Indication però c’è un blocco locale di Confirm che dice che le cose sono state spedite dall’altra parte. Tipica sequenza con connessione: CONNECT apertura della connessione con negoziazione (tipicamente sincrona, tutte e 4 le forme) o molte DATA invio dati o o DATA.request - Invio dati o DATA.indication - Segnala dati con la qualità della connessione DISCONNECT chiusura della connessione o OSI tipicamente con QoS e impegno intermedi TCP/IP solo best effort e impegno solo endpoint
2
OSI – Livello Network Tiene conto dei nodi intermedi tra due pari. Il livello di network si occupa delle diverse realizzazioni di routing tra reti diverse oltre a definire il sistema di nomi delle entità. Obiettivo: passaggio delle informazioni interferendo meno possibile sul comportamento locale Compiti del Livello di Rete Indirizzamento (vedi nomi di IP) Controllo di flusso tra due pari Controllo di congestione nel sistema intero Obiettivi: migliorare efficienza ed evitare ingiustizia, deadlock Principio di separazione: i nodi intermedi devono potere interagire solo per le funzionalità necessarie e non essere toccati ai livelli applicativi. Nei nodi intermedi di una comunicazione abbiamo solo i livelli fisici -> fino al livello di Rete.
OSI – Livello Trasporto il Trasporto comincia a considerare la struttura dei nodi partecipanti, in particolare gli endpoint. Livello end-to-end per separare i
livelli relativi alla comunicazione da quelli più vicini all’applicazione. Obiettivo: spedizione di dati sul canale di connessione con correttezza, con certi tempi di risposta, e con una certa qualità di servizio, su richieste dal livello di Sessione superiore. In OSI, dal Trasporto in su, tutto è con connessione -> Modalità connection-oriented. Ci possono essere anche modalità non connesse (es Internet). Interazioni con apertura e terminazione (CONNECT e DISCONNECT) della connessione e trasferimento di dati (normali o privilegiati con la primitiva DATA. Ogni livello ha le proprie entità e SAP. Se focalizziamo solo T e N, un nodo potrebbe avere molte SAP di trasporto e una sola di rete: in questo caso le applicazioni devono specificare quali enti sono coinvolti per ogni comunicazione. Il trasporto può spezzare il dato e ricomporlo dopo averlo portato suddiviso fino al pari Il trasporto può lavorare unendo o decomponendo flussi di trasporto rispetto a quelli di rete (Multiplexing). Può essere fatto verso l’alto e verso il basso. Primitive – Livello di Trasporto T-CONNECT Servizio confermato (sincrono) T-DATA Servizio non confermato (asincrono) T-EXPEDITED-DATA Servizio non confermato (asincrono) T-DISCONNECT Servizio non confermato (asincrono)
Indirizzo del chiamante e del chiamato, opzione per l’uso di dati privilegiati, qualità di servizio e dati d’utente (4 primitive) Dati di utente (normali). Dati di utente. Dati che devono essere consegnati in modo preferenziale (urgenti). Ragione della terminazione, Dati di utente.
OSI – Livello Sessione La sessione si occupa del controllo del dialogo: nei sistemi con sessione posso strutturare il dialogo in modo molto Dialogo è fatto di attività. Le attività sono separate e indipendenti (se fallisce/termina una non influenza in nessun modo le altre) (Processi) nell’ambito della stessa connessione tra due entità. In Internet il livello di Sessione è assolutamente vuoto (tutto in mano al programmatore). Socket non hanno sessione in accordo con OSI. Nella sessione il dialogo può essere bidirezionale, molteplice (strutturato in attività separate e diverse), considerare le risorse impegnate e avere garanzie di correttezza e affidabilità. Primitive – Livello di Sessione Nella sessione coordina il dialogo basandosi sul servizio offerto organizzato in unità funzionali. Ognuna legata da un insieme di primitive e parametri. Le primitive sono 58 raggruppate in 14 unità funzionali. Uso di connessione, con QoS negoziata, e semantica più complessa. Il dialogo è strutturato attraverso azioni di controllo, attività, eccezioni. Il livello di Sessione fornisce servizi analoghi a quelli del livello di Trasporto, e ogni livello: Apertura e Chiusura della connessione Trasferimento dati, fino a 4 tipi di dato Gestione dell’interazione, modalità dialogo half-duplex, full-duplex o simplex Sincronizzazione, inserimento dei punti di sincronizzazione e gestione delle eccezioni.
3
Mittente
Ricevente
Con SYNC (sincrona) se fallisce la connessione l’interazione non riparte dall’inizio ma da questo punto di sincronizzazione. Richiede all’altro di ricevere tutti i dati e garantire successivamente di confermare la S-DATA … ricezione dei dati (S-DATA asincrona). Esistono due tipi di punti di sincronizzazione: 1. Punti di sincronizzazione maggiore il mittente attende (modo sincrono bloccante) che il ricevente confermi. (Attesa) 2. Punti di sincronizzazione minore (invio con conferma o meno) , il mittente può continuare a spedire dati o punti di sincronizzazione. Il mittente non deve segnalare la ricezione di un punto minore e la conferma di un punto minore conferma anche tutti i punti precedenti (Accumulo e poi Attesa) a. Sono gestiti a finestra, rappresentano una modalità di sincronizzazione differita e non immediata. Si definisce una finestra che rappresenta il numero massimo di punti di sincronizzazione non confermati che si possono avere pendenti. Quando una finestra si riempie -> Attesa di conferma. Ad ogni c onferma la finestra scorre (sliding window) I punti di sincronizzazione di un dialogo possono essere usati nel recovery per ritrovare uno stato significativo. Strategie diverse: abbandono, ripristino, ripristino diretto dall’utente. Punti maggiori e minori possono coesistere nella stessa connessione rendendo molto articolato il dialogo. Le connessioni tipicamente sono bidirezionali. In alcuni momenti però solo una delle due entità connesse gestisce certe attività. La primitiva S-CONNECT per stabilire la connessione permette di negoziare anche i token che rappresenta un’autorizzazione per effettuare una certa operazione (es Sync) ad esempio, l'utente che richiede la connessione e l'utente che la accetta indicano i servizi da implementare. L'intersezione dei due insiemi di requisiti determina la S-connessione. Vari tipi di token distinti come diritto di: data token: spedire i dati in Half Duplex release token: richiedere la terminazione synchronize minor token: creare punto di sincronizzazione minore synchronize major token: creare punti maggiori S-CONNECT S-DATA … SYNC ->
OSI – Livello di Presentazione Il livello di presentazione è il livello che si occupa di gestire la rappresentazione dei dati. In sistemi eterogenei è assolutamente necessario gestire la rappresentazione dei dati. Ad esempio nelle Socket: htonl e ntohl (Internet big-endian). Necessità di codifiche diverse:
Differenze naturali tra i sistemi che comunicano
Migliorare la comunicazione (efficienza e sicurezza) (Compressione e criptazione)
I dati devono essere scambiati dopo un accordo tra i pari che superi i problemi di eterogeneità. In OSI si prevede una fase statica iniziale di accordo tra le parti per definire i tipi di dati e di c onnessioni. Ma, in OSI, questo si può fare anche in modo dinamico, durante l’esecuzione.
In caso di N nodi eterogenei nel primo caso le funzioni di conversione sono N*(N-1) nel secondo sono N verso ed N per il formato comune. Si usa sempre e solo la seconda. Solo trasformazioni dallo standard definito al nodo e viceversa. Differenza: Invece di una trasformazione se ne fanno due. In questo modo, ogni nodo, conosce solo la sua trasformazione e quella standard e questo facilita anche l’aggiunta di altri nodi nel sistema. Per scalabilità. Dati e Formati Tipicamente in una comunicazione vengono scambiati dati. La comunicazione può introdurre errori e corrompere un dato inviato. Vengono introdotte delle ridondanze per verificare che il dato ricevuto non sia stato corrotto. Quindi si possono inviare informazioni aggiuntive (descrizioni) che qualificano il dato inviato -> Impegno di banda maggiore per avere affidabilità. Per il formato dei dati ci sono due tipi di approccio utilizzabili: Statico: i due nodi che comunicano hanno già scritto al loro interno il tipo di dati che verranno scambiati. Buono per sistemi piccoli. Tempo di vita breve. Dinamico: Trasferimento di informazioni sul tipo di dati non note a tempo di progetto. Accordo da stabilire durante l’esecuzione. OSI descrive anche come (fasi) deve avvenire l’accordo (descrizione astratta dell’accordo). Astratta perché vengono descritti i dati in modo astratto. Indicato per sistemi grandi e eterogenei. Tempo di vita lungo.
4
Accordo – Trasformazioni e Ridondanza
Possiamo usare diversi gradi di ridondanza a secondo del costo associato alla comunicazione (impegno di banda) I dati possono essere:
valore
lunghezza del valore, valore
tipo, lunghezza campo valore, valore
Se non c’è un accordo bisogna stabilirlo attraverso un linguaggio comune e standard per l’accordo. Molto spesso i linguaggi astratti, nel livello di presentazione, prevedono molte fasi di negoziazione non prevedibili poiché non si può sapere a priori il numero preciso di stack di rappresentazioni del singolo nodo. I protocolli del livello di presentazione sono molto complessi. API molto numerose divise in unità funzionali. Necessità di accordarsi e definire:
Contesto di comunicazione (magazzino)
Soggetto della comunicazione (scorte del magazzino)
Semantica delle informazioni (dominio comune di cui vogliamo parlare)
Informazioni vere e proprie (dati re lativi)
Protocolli di Negoziazione Protocolli multifase -> numero di informazioni scambiate molto maggiore rispetto ad una interazione cliente/servitore. BIDDING (asta, offerta) (Contract Net) tra sender e receiver si prevedono molte fasi (almeno 5 anche ripetute). È stato definito per il settore dell’IA, di livello applicativo, molto costoso, usato per sistemi ampi in cui si vuole raggiungere una risorsa che può essere offerta da più contraenti nel sistema. 1. Sender fa un broadcast della propria esigenza (ANNOUNCE) 2. Receiver fanno un'offerta (BID). Contiene anche QoS. 3. Sender sceglie tra i bid dei receiver. (AWARD). Manda un messaggio al contraente. 4. Receiver accoglie l'ok definitivo (contract). 5. Accordo Se il receiver è occupato: alla fase 4, il receiver può rifiutare e si riparte da 3 (o da 1). Soluzione molto flessibile ma costosa e non ottimale. Nel distribuito non ottimo perché si potrebbe mancare un’offerta migliore (che viene dopo ad esempio). BER e ASN.1 OSI per il livello di presentazione definisce due standard: • Un linguaggio astratto di specifica (parte astratta accordo) o
ASN.1 (Abstract Syntax Notation) Linguaggio usato in modo astratto per descrivere le funzioni di accordo fra entità che non si sono accordate in modo statico.
Non descrive solo i dati ma è anche possibile descrivere in modo non ambiguo le informazioni che servono per stabilire il contesto, il soggetto, la semantica di comunicazione. Usato raramente (in caso di bisogno) in casi in cui deve essere fatto un accordo in modo dinamico. Si può descrivere, e quindi comunicare, anche del codice. •
Un linguaggio concreto di descrizione dei dati (parte concreta accordo) BER (Basic Encoding Rules): Regole di codifica della rappresentazione standard che viene scambiata tra un nodo ed un altro. Usato sempre perché fornisce la descrizione dei dati veri e propri. Ogni dato deve viaggiare con una tripla (Tag-Length-Value, tipo-lunghezzavalore).
o
In questo modo viene introdotto molto overhead a vantaggio della affidabilità. In internet, ad esempio, viene inviata solo la parte di value (best-effort). Formato standard da cui ricevono/attraverso cui vengono scambiati i messaggi
5
OSI – Livello di Applicazione Il livello di Applicazione è il livello che si interfaccia con l'utente finale della comunicazione in base al modello OSI. Obiettivo Astrazione nascondere la complessità dei livelli sottostanti coordinando il dialogo tra le applicazioni distribuite.
Il livello applicativo OSI standard definisce un insieme di servizi indipendenti dal sistema e li fornisce a programmi di utente o ad utenti - diversi servizi ed ambienti standard (ISO 9545): Message Handling System MHS (es email)
Directory service X.500
System Management X.700 Common Management Information Service & Protocol CMISE & CMIP File Transfer, Access and Management FTAM (anche per file molto complessi in termini di struttura) Virtual Terminal Standard VT (es telnet) Distributed Transaction Processing DTP OSI adotta un approccio particolare basato sul modello ad Oggetti per la specifica delle applicazioni. Uso di template e package per definire gli oggetti. Pura ereditarietà statica tra astrazioni. Oggetti da manipolare come interfaccia ed espressi attraverso l'uso di package (anche condizionali). Unicità dei nomi necessaria come presupposto di base per l’accordo e il coordinamento. NOMI UNICI come servizio (X.500). La struttura delle applicazioni OSI è a livelli. Alla base dei servizi forniti dal livello di applicazione ci sono un po’ di strumenti: ACSE (Association Control Service Element) di base per ogni servizio RTSE (Reliable Transfer Service Element) per ottenere servizi affidabili ROSE (Remote Operation Service Element) per operazioni remote CCR (Commitment Concurrency and Recovery) per azioni multiple coordinate
Servizi X.500 (Directory)
Il servizio di direttorio consente di collocare e classificare ogni entità di interesse (ogni dispositivo noto) in base al contenuto degli attributi in un sistema gerarchico (ad albero) di conoscenza, molto accessibile (24/7). Spesso si riferisce una entità attraverso il suo identificatore specificato come sequenza di decisioni e scelte (1.3.6.1.2.1.4) Il sottoalbero per la descrizione del protocollo IP per gestione Negli altri casi, si negoziano le proprietà con ASN.1.
6
Reti e Routing Reti Le reti permettono ed attuano le interconnessione tra i diversi sistemi di calcolo. Le reti sono il mezzo di interconnessione punto a punto o via comunicazioni globali che coordinano molte entità. La rete è misurata dal costo, velocità ed affidabilità di invio dei messaggi, nell’intero percorso da dove provengono a dove devono essere consegnati. Le reti si possono misurare in molti modi e secondo molte metriche. Le reti come mezzo di interconnessione punto a punto o via interconnessioni di molte entità (es multicast e broadcast) Parametri:
Tempo di latenza (tempo di ritardo sulla comunicazione)
Banda (quantità di dati trasmessi per unità di tempo)
Connettività (tipo di interconnessione e topologia)
Costo apparati
Reliability (affidabilità) (percorsi ridondanti)
Funzionalità (ad esempio, attraverso operazioni sui messaggi come combinazione e frammentazione dei messaggi e
ricomposizione) Topologie Le reti possono adottare molte topologie, o statiche (reti dirette) o dinamiche (reti indirette). Le reti dirette statiche prevedono architetture non variabili, fissate, definite, e regolari di interconnessione. Bus: (ethernet CSMA/CD) tutti trasmettono nello stesso canale comune. Problema: molto traffico -> Molte collisioni -> Operatività limitata. Bus (dinamico): interconnessione di tutti i nodi
attraverso un unico mezzo di interconnessione -> bus dinamico unico. Va usato bene in accesso considerato che il mezzo è condiviso. Se un nodo sta comunicando gli altri attendono. Mesh: Ogni nodo ha un numero di vicini. Le connessioni
verso un altro nodo sono molteplici -> in caso di guasto posso comunque comunicare. Queste topologie vengono realizzate in reti relativamente piccole per ottenere qualità di servizio. Ipercubo è una topologia regolare che prevede un grado di connettività crescente.
Molte architetture parallele usano questa topologia perché consente di avere tempi di latenza molto bassi visto che il numero di link per nodo è abbastanza elevato. In un ipercubo di dimensione 4 ogni nodo ha 4 link per comunicare con gli altri nodi -> il numero di link è pari alla dimensione del cubo -> Problema del Costo di interconnessione. Interconnessione Completa: interconnettere tutti con tutti. Con n elementi, n^2 connessioni con il costo conseguente di una serie di
switch hardware.
Switching L’interconnessione di diverse entità deve ottimizzare l’uso delle risorse e metterle a disposizione in modo dinamico di chi manifesta la necessità di uso. Lo switching permette di dedicare le risorse a più richieste in tempi diversi e non mantenerle allocate ad un unico obiettivo di connessione. Lo switching permette di prevedere un impegno anche condiviso delle risorse per consentire di passare i dati in caso di nodi non in visibilità in modi diversi. Nel caso di messaggi diversi, possono essere frammentati in pezzi corti che possono viaggiare insieme su tratte di reti disponibili. Nelle reti si fa Switch di Pacchetto che può avvenire attraverso canali creati dinamicamente (circuiti virtuali) cioè risorse dedicate nei nodi intermedi o essere del tutto libero senza stabilire connessioni di alcun tipo (usando frammentazione in datagrammi)
1
Reti Omega Reti basate su una sequenza di switch binari che, con un costo più basso, permettono di ottenere lo stesso effetto di una
matrice di switch. Reti a stage che interconnettono p elementi, con log2(p) stage; ogni stage ha p input e p output. Comandando gli stage composti da switch binari, si ottengono dinamicamente le potenziali interconnessioni desiderate Switch di Circuito Ossia avere canali dedicati (o connessioni statiche) predeterminati e mantenuti anche se non usati -> A priori,
staticamente, conosco il cammino che congiunge mittente e destinatario di una comunicazione. Questo modo di lavorare non è mai utilizzato in internet, ma in OSI sì, dove bisogna garantire ad esempio la banda durante il cammino -> Qualità. Molto spesso vengono realizzati circuiti virtuali. Permettono la condivisione delle risorse per ottenere un migliore uso del sistema di comunicazione. Sia circuiti dedicati che virtuali non sono attuabili in TCP/IP -> solo switch di datagrammi Switch di datagrammi Nessun circuito o canale, ma solo datagrammi, unità di trasmissione, che possono essere mandate tra nodi vicini
(politica ottimista) mirando ad ottenere il migliore uso del sistema di comunicazione Comunicazione a datagrammi (tecnica ottimista): Con i datagrammi, non si garantisce nessuna connessione end-to-end, e quindi nessun controllo flusso, nessuna garanzia (no ordine, no QoS). Ogni entità da inviare (datagramma) porta indirizzo del ricevente e viene smistato in modo indipendente; si possono introdurre molti ritardi e jitter. Congestione -> si lavora male. Controllo delle reti Se dobbiamo gestire connessioni abbiamo necessità di operazioni per preparare la comunicazione (stabilire la
connessione), mantenerla e garantirla, e chiuderla al termine. Possibilità di Segnalazione (o Controllo)
I dati e/o i controlli, all’interno del mezzo, possono essere trasmessi: in-band: usando gli stessi cammini e risorse per i dati out-of-band: cammini separati per il controllo e il signaling Ci sono diversi livelli di comunicazione: Piano User (protocolli utente) (in-band) o Livello applicativo Piano di Controllo (controllo connessione) (out-of-band) o Controlla come va la connessione ed eventualmente la migliora in termini di qualità Piano di Management (stabilire e gestire il canale) ( out-of-band) Stabilisce la connessione. Allocazione e deallocazione delle risorse per ottenere un servizio. o Controllo e management sono necessari entrambi per ottenere qualità. Internet usa solo il piano utente (controllo in banda -> intrusione).
Reti Spesso i sistemi di interesse sono costituiti da reti molto differenziate ossia reti destinate a interconnettere entità geograficamente molto eterogenee Wide Area Network – WAN per reti geografiche anche a copertura molto ampia (globale) o Si trovano in mesh, reti magliate e ridondate, come nel sistema telefonico, Public Switch Telephone Network (PSTN) Metropolitan Area Network – MAN area di copertura di una città Local Area Network – LAN reti di dimensione limitata e con forte limitazione sui partecipanti o Sono state usate molto come banco di prova e di esperienza dei protocolli, oltre che ampia palestra di uso Alta velocità ed ampia banda di trasmissione o
o
Facilità di broadcast
o
Bassa probabilità di errori
o
Topologie utilizzate:
Stella, come i PABX (Private Automatic Branch Exchange)
Bus anche un insieme di bus interconnessi
Ring (anello)
Hub, ossia un bus inglobato in una unica unità centrale di connessione, simile al nodo centrale di una stella
Personal Area Network – PAN reti di dimensione veramente limitata e ad uso di utenti singoli con tecnologie ad hoc e propagazione ancora più limitata (reti wireless)
2
Controllo d’accesso
Tipici controlli di accesso sono (standard IEEE 802.x): CSMA/CD (Ethernet), standard 802.3 Carrier Sense Multiple Access/Collision Detection. Accesso ottimistico, reattivo, dinamico al bus, in caso di impegno si deve avvertire la collisione e ritrasmettere con intervallo random. Token (control token o token ring), standard 802.5 Accesso pessimistico garantito da un ring in modo statico: in un anello un solo possessore del token ha il diritto di trasmettere; si forza il passaggio del token da un vicino ad un altro dopo un intervallo. Slotted ring (anello a slot), standard 802.4 Accesso pessimistico usando messaggi che circolano in modo proattivo sul ring; anello come insieme di contenitori di messaggi circolanti (o slot) che possono essere riempiti se vuoti.
Interconnessione tra reti
Possiamo avere molti apparati per interconnettere e/o separare entità a diversi livelli OSI Ripetitori: rigeneratori di un segnale a livello fisico, superando e rimediando ad un’eventuale livello di attenuazione. Un ripetitore non effettua alcuna separazione. (livello fisico - 1) Bridge: apparati che collegano reti diverse, con capacità di separazione e maggiore intelligenza ( livello data link - 2) Router (o gateway): apparati e sistemi per il passaggio da una rete ad un'altra con obiettivo di supportare la comunicazione dei messaggi ed il routing (livello network - 3) Protocol converter: sistemi che collegano reti diverse a più alto livello con protocolli diversi di interconnessione (dal livello di trasporto in su)
Bridge (Livello Data Link – 2 OSI) Un bridge collega e separa due (o più) reti a livello di data link, controllando il passaggio e la separazione delle due reti, ad esempio passando e bufferizzando (nella sua memoria) i frame dall'una all'altra, solo se necessario, e trattando anche situazioni di errore. Vantaggi
• • • •
Separazione effettiva delle reti Bufferizzazione dei frame (trattando il caso di overflow)
Capacità di gestire controlli di accesso diversi (topologie e protocolli diversi in due reti) Monitoring della rete: della performance ed affidabilità
Svantaggi
• Ritardo di bufferizzazione • Bufferizzazione limitata e non infinita • Trasformazione dei frame (con controllo) I bridge possono lavorare in molti modi diversi • Bridge multiporta, collegano più segmenti di rete diversi (statici) • Bridge trasparenti, che operano in modo invisibile agli utenti (dinamici -> con fase di learning) Devono collegare solo le entità interessate, ossia bloccare i pacchetti che devono rimanere locali e fare passare solo ciò che deve transitare Si parla di routing isolato, anche se siamo a livello di frame, e dobbiamo avere previsto un database di forwarding • Informazioni della tabella come database in PROM • Bridge con capacità di apprendimento osservando il traffico. Il bridge impara la allocazione vedendo il traffico della rete e dai vicini (il tutto è ripetuto quando è necessario coordinarsi). All’inizio fanno passare tutto. Vedendo da dove arrivano le informazioni stabilisce dove sono allocate le connessioni (entità) della rete. Se si usano molti bridge, non si potrebbe riconoscere facilmente la collocazione delle connessioni. Soluzione: Bridge con priorità -> Viene definita una struttura ad albero di bridge nella fase precedente alla fase di apprendimento. Algoritmo spanning tree - i bridge si scambiano messaggi per trovare i costi più bassi di collegamento e costruire un albero unico che percorre tutta la topologia di collegamenti. Si sceglie un bridge radice tra tutti e ognuno degli altri trova il cammino minimo per collegarsi a lui (passi e velocità). Bridge rimangono in una sola rete, solo tra tratte diverse della stessa rete. Route e Routing (Livello Network – 3 OSI) Il problema del cammino dal sorgente al destinatario in caso di comunicazione viene affrontato dal routing attraversando un insieme di nomi intermedi (dinamica) -> Necessità di mapping efficiente. Quando arriva un datagramma in un ingresso il router deve sapere esattamente dove farlo uscire per farlo arrivare a destinazione (prossimo hop o destinatario).
3
Proprietà del routing
Correttezza Percorso più breve (per numero di hop, tempi o altro) verso la destinazione.
Semplicità Algoritmi di smistamento devono essere semplici e ben realizzati
Robustezza (tolleranza ai guasti e variazioni) Reazione corretta alle sollecitazioni.
Stabilità della soluzione: Politiche e soluzioni che non cambiano nel tempo. Garanzia che la situazione di regime venga stabilita
in tempi brevi e che rimanga operativa a lungo. Ottimalità Molte variabili da ottimizzare. Fairness (giustizia) Nessun Privilegio -> FIFO. Non consente di gestire la QoS.
Classificazione Routing
Classificazione delle strategie di routing Globale: c’è un’entità che può vedere globalmente lo stato di tutto sistema e attuare decisioni a livello globale. Problemi di scalabilità. Locale: ogni nodo prende decisioni di routing. Isolato perché ogni nodo ha delle strategie proprie, con visione limitata e costo basso Statico: routing in cui le strade da seguire sono decise in modo molto proattivo (staticamente). Molto poco flessibile. Dinamico: prende decisioni che tengono conto dello stato del sistema. È più costoso perché, durante l’esecuzione deve fare delle operazioni (Visto che siamo in-band) Adattattivo: Si adatta ai cambiamenti (fallimenti) nella rete, si sfruttano anche le risorse libere in modo dinamico Non Adattattivo: NON si adatta ai cambiamenti (fallimenti) nella rete. I cammini sono fissi e non variano. anche non deterministico / deterministico
Strategie di Routing Per la classificazione si possono considerare molteplici attributi e ruoli 1. Chi prende le decisioni di routing 2. Chi attua le decisioni di routing 3. Il momento delle decisioni di routing 4. Il controllo del routing adattativo 1. Chi prende le decisioni di routing
Sulle strategie di routing, le decisioni prese da diverse entità Sorgente (source route) Il mittente specifica l'intero cammino (in modo stretto e completo o solo parzialmente); gli altri devono rispettare la decisione (statica per il datagramma).
Hop-by-hop
Ogni nodo ha uno scope di decisione e decide lui il prossimo hop. Decisione e strategia distribuita. La decisione non viene guidata dal mittente, ma decisa ad ogni passo e ad ogni intermedio in modo indipendente il sorgente non conosce il cammino e neanche gli intermedi che comandano solo la propria uscita. Potrebbero non raggiungere tutti i nodi. Tabelle locali.
Broadcast
Si invia ad ogni possibile entità ricevente il messaggio ed ognuno lo riceve (costoso): non ci sono decisioni per il mittente ma consegna a tutti (eliminando duplicati). Applicabile in sistemi molto limitati. 2. Chi attua le decisioni di routing
Sulla attuazione delle decisioni di routing, dobbiamo considerare il ruolo dei router intermedi che provvedono funzionalità opportune Le decisioni possono essere attuate da agenti intermedi. Unici e centralizzati (usato raramente) Un unico gestore del routing prende le decisioni: questo consente di ottenere anche decisioni ottimali sull’intero sistema. Per sistemi piccoli o in aree limitate. Distribuiti Non esiste un unico luogo di controllo ma una serie di entità distribuite nell’intero sistema e che si occupano del routing, in modo più o meno coordinato.
3. Il momento delle decisioni di routing
Per l’aspetto di tempo delle decisioni di routing, si considera routing: Statico (fisso o deterministico) La strategia di routing rimane fissata nel sistema e non cambia. Dinamico (adattativo) L’algoritmo di routing evolve e si può adattare alle informazioni di stato del sistema, in modo da ottenere un costante adattamento alla situazione corrente. Supera problemi e guasti non previsti ad esempio.
4
4. Controllo routing adattativo In caso di adattività, si deve prevedere una costante interazione con le risorse impegnate
Dal punto di vista della comunicazione, possiamo avere Switching di Pacchetto (Internet) o uso di Circuit Switch ossia canali predeterminati. La scelta del cammino tra quelli possibili in modo fissato o meno, adattandosi o meno allo stato del sistema. Si noti che normalmente si considerano solo cammini minimi (ottimi). In alcuni casi si possono anche prevedere cammini non minimi facendo misrouting (capacità di scegliere una strada diversa se quella ottima non rispetta più alcune caratteristiche di qualità o è congestionata ad esempio). Algoritmi tipici di routing Shortest Path First (Dijkstra) Ogni nodo costruisce un grafo completo dell'intera interconnessione, stabilendo una metrica di distanza in base a pesi. Con successive iterazioni, si calcolano le distanze minime per ogni nodo (da scegliere successivamente). Il traffico di routing segue il cammino più corto determinato. Ogni nodo è responsabile per il routing. Svantaggi / Vantaggi
Costo della propagazione dei valori in caso di variazione. Possibilità di usare al meglio tutte le risorse esistenti. Implementazioni (famiglie)
Algoritmi Spanning tree (statico) (single-path)
Si tende ad identificare un albero di interconnessione tra tutti i nodi della rete, consentendo la eliminazione dei cicli e determinando cammini senza problemi in modo globale. Non è ottimo -> tutti i nodi occupano gli stessi cammini -> congestione.
Algoritmi Distance Vector (dinamico) (single-path)
Per ogni gateway, la tabella mantiene la sola distanza in passi e il primo passo di uscita per il routing. Le tabelle sono minime e consentono un istradamento statico facile. Problemi nei cambiamenti e nella propagazione delle variazioni. Sistema poco coordinato. Usato in internet dall’inizio. Single-path -> tutto il traffico da una rete ad un’altra passano su solo cammino. Non reagiscono molto bene e hanno tempi di adattività non accettabili.
Algoritmi Link State (dinamico) (multi-path) Ogni nodo mantiene tutto il grafo e tende a limitare la propagazione delle informazioni, rendendo facili anche cammini
multipli. Variazioni (fallimenti) sono propagate in broadcast, spesso uso di spanning tree. Sono interessanti ed usati anche algoritmi MULTIPATH ossia strategie che permettano di utilizzare anche più possibili percorsi per uno stesso destinatario. In Internet non si usa molto il multi-path. Internet lavora a livelli applicando in base al livello diversi algoritmi. Algoritmi Backward Learning
Ogni messaggio porta l'indicazione del mittente e, quindi, consente di inferire la distanza del mittente stesso ad ogni messaggio I nodi intermedi possono stimare la distanze e la topologia. La fase iniziale di apprendimento dell'algoritmo deve lavorare in base ad una politica, da cui dipendono le stime successive. La conoscenza della topologia della interconnessione completa (globale) permette di evitare situazioni di ciclo o livelock (messaggio continua a circolare senza andare da nessuna parte) in cui un messaggio si perde in passaggi inutili ripetuti. Algoritmi isolati e adattativi
Strategie dinamiche indipendenti dalla topologia di interconnessione che si basano su informazioni solo locali (isolati) o solo di vicinato (distribuiti e locali) possono essere molto efficaci. Vantaggi ad esempio se un nodo “si muove”. Algoritmo Random, se non a destinazione, ogni messaggio, viene smistato con scelta casuale dell’uscita (non input). Algoritmo Patata Bollente: Un messaggio viene smistato (se non a destinazione) attraverso la coda di uscita più scarica del nodo. Non si può predire il numero di passi per arrivare a destinazione e dipende dal traffico. Mancano del tutto i costi delle fasi di coordinamento e si limita fortemente overhead in caso di variazioni, e di cammini diversi. Si possono introdurre problemi per la perdita della visibilità della topologia e del coordinamento: sono possibili cicli o livelock. Algoritmo Flooding Un messaggio viene smistato (se non è arrivato a destinazione) attraverso tutte le code di uscita del nodo (nella direzione giusta). Uso di contatori per limitare i passi di un messaggio. Uso di identificatori per evitare generazione senza fine.
5
Teorema per sistemi ideali di inte rconnessione (a messaggi)
Algoritmo di routing ottimale in un sistema dinamico con un numero infinito di nodi è una combinazione del routing random. M mittente e D destinatario, si determina in modo random un nodo R (diverso da M e D) e si manda il messaggio in due hop: la prima fase da M ad R e la seconda da R a D. In sistemi globali le tabelle devono essere aggiornate spesso: algoritmi senza tabelle limitano l'overhead e possono consentire di raggiungere destinatari anche in movimento. Ottimalità come uso ottimale delle risorse disponibili, usare al meglio le risorse disponibili. Problemi nel Routing Alcune situazioni sono critiche per il supporto al routing: Congestione Situazione (globale) in cui un area della rete (internet) presenta un carico eccessivo. C’è necessità di controllare gli asincronismi che possono impegnare le risorse e mantenerle. È opportuno un buon controllo dei buffer per evitare il problema (su un nodo/router). Possibilità: Si inviano indicazioni al mittente (messaggi di choke: stop al mittente quando riceve un pacchetto oltre il limite. ICMP) Si scartano tutti i messaggi successivi (tecnica reattiva) Si prevede un numero massimo fisso di messaggi circolanti (tecnica proattiva)
Deadlock impegno totale dei buffer con blocco critico
Avoidance si numerano i buffer e si acquisiscono in ordine (proattiva)
Prevention si mantengono buffer per fare scambi in caso di saturazione (proattiva)
Recovery si tratta il problema quando rilevato (reattiva)
Livelock con messaggi che continuano a permanere nel sistema senza giungere a destinazione (persi in cicli o altro)
Soluzioni a priori si mantiene il cammino percorso e si evitano i loop
Soluzioni a posteriori si elimina il messaggio oltre un certo numero di passi (time to live)
Livello Network Indirizzi IP Sistema di nomi Internet (IPv4), parole di 4 byte (32 bit), diviso in due parti (parte di rete e parte di host). In Internet se si cambia rete si cambia IP (cambiando la parte di rete) -> Tipici della rete in cui ci si trova. I nomi di IP sono dati di autorità dal Network Information Center (NIC) che assegna i numeri di rete, cioè informazione usata nei gateway per routing. La parte di rete quindi è assegnata di autorità. La parte di nodo in IP è soggetta a 3 classi primarie (in base al numero di reti e al numero di host collegabili) e differisce per numero di bit delle singole parti: analizzando un indirizzo IP si può distinguere la classe in modo automatico.
Datagrammi Un Datagramma IP è la unità base di informazione che viaggia in Internet. Contiene una parte di intestazione (di protocollo) e una parte di dati.
6
Header del Datagramma 5 parole di 32 bit, con eventualmente, delle opzioni che possono occupare
le parole da 6 a 16 (parte dati) Header (minimo 20 byte, max 64), e dati. 1. VERS Versione del protocollo, HLEN (4bit) lunghezza dell’header (variabile), TOTAL LENGTH lunghezza totale del datagramma (64k incluso l’header), SRV TP Service Type qualificano il tipo di servizio, sono usati per scegliere
strade diverse. 2. IDENTIFICATION numero associato al datagramma utilizzato nella
frammentazione per identificare i frammenti. FRAGMENT OFFSET offset dei vari frammenti. FLAGS per frammentazione (primo e altri MF a 1 e l’ultimo MF a 0). DNF a 1 il datagramma non viene frammentato. 3. TIME TO LIVE, tempo di permanenza del datagramma (valore decrementato ad ogni hop: se 0 viene buttato), PRTCL tipo di protocollo superiore (anomalia perché non si dovrebbe sapere ma può servire) (TCP 6, UDP 17), HEADER CHECKSUM per il controllo (complemento a 1 a 16 bit) 4. Indirizzo IP del mittente 5. Indirizzo IP del destinatario 6. Opzioni per monitoraggio e controllo rete SeRVice TyPe
Consentono di selezionare il tipo di servizio. Bit da settare: D (Delay): minimizzare il ritardo, T (Throughput) da massimizzare lo throughput, R (Reliability) massima affidabilità, C (Cost) costo minore, PRECEDENCE: selezionare precedenze diverse in base al valore specificato. Protocollo IP I datagrammi viaggiano in modo indipendente e autonomo (anche come sottoparti o frammenti). IP è un protocollo best-effort a basso costo e non garantisce Quality of Service QoS né ordine. Il protocollo IPv4 prescrive come si deve realmente implementare l’instradamento dei datagrammi, obiettivo fondamentale del livello Il protocollo prescrive per ogni nodo che deve comportarsi come un router, ossia fare routing, due funzioni principali da svolgere • Elaborazione del messaggio del livello superiore nel formato per la trasmissione Incapsulamento / Frammentazione. Il datagramma deve contenere le informazioni di livello superiore, o eventualmente i dati devono essere frammentati (se possibile) • Instradamento (routing) cioè: o Traduzione da indirizzo logico IP a indirizzo fisico di frame (ARP) (MAC) Scelta della porta di uscita (in base al percorso) o Invio di un datagramma IP
Un datagramma deve essere smistato da un nodo ad un nodo successivo secondo le normali regole di incapsulamento. Ogni nodo deve incapsulare ogni datagramma in un frame di livello data link (livello 2) (aggiunge indirizzi di livello 2 MAC al datagramma). Ovviamente questo avviene anche per ogni singolo datagramma, e senza legami tra i diversi frammenti e datagrammi, che vengono trattati in modo indipendente dalla driver di routing (FIFO). Ogni intermediario può operare sul messaggio, a partire dal mittente. Ogni nodo può frammentare il datagramma (decomposizione al mittente, decomposizione ad ogni intermediario, ricomposizione solo al destinatario). Frammentazione Datagramma IP
I datagrammi devono essere incapsulati nei frame di livello data link su cui transitano in base alla MTU (maximum transfer unit), ossia la lunghezza massima dei frame a livello f isico (di Internet cioè 2 OSI). Per determinare la dimensione massima del datagramma: 1. Calcolo statico da parte del mittente 2. Decisione passo passo (quella usata) MTU scelta indipendente dalle tecnologie sottostanti per rendere efficiente la comunicazione a livello utente (fissata tipicamente a 64Kb) Il destinatario, unico che ricompone il datagramma, riceve diversi frammenti, li identifica in base allo stesso ID e li mette insieme in base all’offset: se l’intero datagramma è stato ricevuto allora viene considerato, altrimenti viene eliminato.
7
Opzioni: Monitoraggio e controllo rete • Record route: genera una lista degli indirizzi IP dei gateway che il frame ha attraversato (al massimo 9 intermedi) o Otteniamo una indicazione dei gateway intermedi attraversati dal datagramma. • Timestamp: genera una lista dei tempi di attraversamento sugli intermedi. Possiamo ottenere una indicazione dei tempi di passaggio e della permanenza del datagramma nei gateway intermedi (vedi mail) per attuare anche azioni correttive e cercare strade diverse • Source route (instradamento al sorgente): il sorgente fornisce indicazioni sul cammino da seguire nel routing del frame strict source: il datagramma porta nella parte opzione una indicazione di tutti i gateway intermedi da attraversare. o o loose source: indicazione di un insieme di percorsi da attraversare non in modo contiguo ed unico. Numero massimo di parole nella parte opzione del datagramma limite al controllo del percorso: al massimo spazio per registrare 9 passi Famiglie di Algoritmi di routing
Due famiglie principali globali, basate su tabelle.
Distance Vector (dinamico con overhead) o
o o o
Per ogni gateway (router), la tabella mantiene la sola distanza in passi (num di hop) e il primo passo di uscita per il routing. Le tabelle sono minime e consentono un istradamento statico facile. Problemi nella costruzione delle tabelle, nei cambiamenti e nella propagazione delle variazioni. Tabelle non statiche (no prom) ma completamente dinamiche e definite durante l’esecuzione Propagazione:
1. 2.
3. 4.
Ognuno dei gateway vede le reti vicine (distanza 0) (G1) Si scambiano le tabelle (G1 e G2) tra i gateway. Dopo lo scambio asincrono delle tabelle, se l’offerta dice qualcosa di nuovo, aggiorna la tabella, altrimenti la lascia invariata. Non c’è nessuna propagazione di informazioni in broadcast. A regime ogni gateway contiene la distanza di ogni rete -> 100 reti = 100 entry. Algoritmo assolutamente non scalabile. La propagazione è molto lenta (esponenziale con il numero dei nodi) Se si inserisce una nuova rete (es tra G1 e G3): se ne accorgono G1 e G3 inizialmente e per G1 diventa una scorciatoia per arrivare a G3. Il cambiamento non viene assorbito velocemente da tutta la rete. Problema Counting-To-Infinity
Una volta definita una tabella e i relativi percorsi il traffico verso una certa rete seguirà sempre lo stesso percorso.
Se un link cade, e da una parte c’è una rete magliata, in questa rete iniziano a essere scambiate offerte che possono essere accettate (erroneamente) e ciò prosegue all’infinito. Problema generale dovuto al non tenere traccia di chi fornisce una distanza da un nodo (e cammino relativo) che rende possibile utilizzare l’offerta anche se non rilevante o affidabile. In un primo momento è stato risolto limitando il numero di passi a 16. Strategie migliorative Split Horizon: per evitare di passare informazioni sbagliate, non si offrono cammini ai nodi da cui le abbiamo ottenute (necessarie maggiori informazioni) -> non si propaga solo la distanza ma anche chi l’ha fornita. Problemi con
reti magliate. Hold-Down: stabilisce un protocollo più coordinato quando c’è una variazione. Dopo una notifica di un problema, si ignorano le informazioni di cammino per un certo intervallo: tutti hanno modo di accorgersi del problema e non ci
sono propagazioni errate.
8
Split Horizon con poisoned reverse e triggered broadcast: In caso di variazione, ogni nodo invia immediatamente un
broadcast con la indicazione del problema ed il cammino. Poco scalabile (per il broadcast -> costoso).
Link State (dinamico con overhead) o
o
o o o
o o
Ogni nodo mantiene tutto il grafo, rendendo possibili anche cammini multipli e quindi sfruttando meglio le risorse.
Quindi ogni gateway ha una conoscenza completa della topologia di interconnessione -> Possibilità di MultiPath. Il LS permette intrinsecamente la possibilità di fare source routing e anche di spedire messaggi diversi su cammini diversi (routing dinamico) e di utilizzare tutte le risorse di interconnessione. Si tende a limitare la propagazione delle informazioni. Le variazioni sono propagate in broadcast. Capacità espressive superiori. Tabelle di routing basate sulla conoscenza dell'intero cammino e tipicamente stabilisce percorsi unici da ogni nodo ad ogni rete. Il grafo di interconnessione, per evitare cicli, viene gestito con algoritmi che possono favorire decisioni locali (routing dinamico) -> (Dijkstra) shortest-path-first. Struttura ad albero – > nessuna maglia. Non scalabile per le dimensioni del grafo. Ogni gateway tiene sotto controllo le proprie connessioni e le verifica periodicamente invio periodico di un messaggio ai vicini per controllo della correttezza delle risorse locali Identificazione del guasto (uso di messaggi specifici per evitare transitori in caso di variazione) Non appena si verifica un problema, chi ha rilevato il problema invia il messaggio di variazione a tutti i partecipanti (broadcast o flooding del messaggio). Propagazione non lenta come DV ma comunque molto costosa. Tempi di down più limitati.
Vantaggi o o o o
Si controlla solo il vicinato Azioni di variazioni propagate rapidamente (senza ambiguità) Possibilità di scelte differenziate dei cammini nella topologia Conoscenza dei cammini completi e source routing Svantaggi
o o
Necessità di mantenere tutta la topologia Azioni costose (broadcast) in caso di variazione
In generale, necessità di limitare i domini di conoscenza reciproca. Tutti i protocolli dinamici sono poco scalabili in caso di variazioni (causa broadcast) Algoritmo Shortest Path First (OSPF) Dijkstra
Protocollo usato in sistemi Link State per determinare i percorsi da usare nel routing. Ogni nodo costruisce una propria tabella di cammini in modo iterativo e la usa per il normale routing. Per ogni altro nodo, si deve memorizzare il cammino che permette di raggiungerlo, tenendo come base il grafo di interconnessione (che viene mantenuto aggiornato). L’algoritmo permette di calcolare il routing di tutti i cammini minimi considerando l’albero che parte dal nodo stesso (spanning tree) L’algoritmo funziona in modo iterativo per passi, e comincia a calcolare le distanze dai vicini adiacenti, poi i nodi di distanza due hop ecc. fino a trovare un albero completo di cammini minimi. Dopo N-1 cicli si raggiungono tutti i nodi e trovato tutti i percorsi minimi.
Routing Internet In Internet si lavora con degli indirizzi IP che rappresentano una connessione. La connessione è stata pensata per un indirizzamento punto-punto. Internet prevede una strategia precisa per raggiungere tutti i possibili nodi che possono intervenire in una comunicazione.
Ogni connessione appartiene ad una rete ed una sola
per connessioni punto-a-punto
Ogni connessione è libera di indirizzare nella ret e facendo operazioni solo locali e a basso costo
per comunicazioni punto-a-punto o broadcast
Ogni connessione può indirizzare in Internet (in modo globale) ma deve usare opportuni intermediari
routing previsto per Internet basato su responsabili della comunicazione globale a costo più elevato L’insieme delle reti Internet tende a minimizzare il costo di supporto
Basata sulla separazione delle reti e sulla loro interconnessione.
RETI uniche logicamente connesse
RETI fisiche separate
9
del routing.
Indirizzamento diretto solo nell’ambito di nodi della stessa rete, altrimenti si devono usare gateway, ossia nodi
intermediari con
almeno due indirizzi IP, ossia connessioni su reti diverse che connettono reti diverse. Sottoreti
Possibilità di limitare la visibilità all’interno di una rete per garantire una migliore propagazione dell’informazione. Un nodo in una sottorete può comunicare direttamente con ogni nodo della sottorete e non può comunicare direttamente con nodi di altre sottoreti. In modo operativo, ogni nodo divide il campo host in subnet+host
In reti di classe B, subnet host suddiviso in 8 bit e 8 bit dida01 137.204.56 subnet 56 deis33 137.204.57 subnet 57 In questo modo riconosce le proprie limitazioni, usando i router anche per comunicazioni all’interno della sua rete stessa. DALL'ESTERNO DELLA RETE -> il subnetting è invisibile e non produce alcuna differenza. Maschere (NETMASK): sono 32 bit a 1 o 0. I bit a 1 specificano la rete che si sta considerando a livello globale, quelli a 0 lasciano la visibilità diretta all’interno della specifica rete. NETMASK esempio maschera in classe B (per 3 byte) 11111111 11111111 11111111 0000000 o 255.255.255.000 La maschera è in sostanza un insieme di bit a livello di rete che determina quali siano i limiti di comunicazione che richiedono un router apposito per uscire FUORI dalla SOTTORETE. In Internet si attua un Routing Gerarchico per aree distinte di gestione e con domini amministrativi diversi.
Unico protocollo di routing per area. La connessione tra le aree avviene attraverso gerarchie di router. Distinzione tra sistemi core e noncore (ARPANET) core insieme di gateway chiave con tabelle complete (e replicate) non core con informazioni di routing solo parziali (e locali) I nodi CORE si scambiano tutte le informazioni di routing (algoritmo Distance Vector e Link State) Scalabilità? problemi aumentando il numero delle reti -> Necessità di routing con astrazione e gerarchia. Introduzione dei sottosistemi autonomi (di livello inferiore). Insieme di reti e gateway controllati da una autorità unica centrale, con proprie politiche di routing interne e non visibili Alcuni gateway di controllo provvedono al protocollo verso l'esterno
o
Exterior Gateway Protocol (EGP)
Protocollo del gateway di controllo per trovare il percorso fino ai core. Struttura ad albero con i core come radice I sistemi autonomi devono scambiarsi informazioni di routing e coordinamento solo intra-sistema o
Interior Gateway Protocol (IGP)
Protocollo per trovare il percorso all' interno di un sistema autonomo (intra-sistema). Politica che consente percorsi multipli e con possibilità di tollerare i guasti (algoritmi multipath IGRP CISCO)
Routing Locale Internet Routing Information Protocol (RIP) implementato in routed UNIX
Nodi attivi e passivi
ATTIVI partecipano a determinare i percorsi (router)
PASSIVI restano ad ascoltare le decisioni degli altri (nodi)
Si manda un messaggio ogni 30 secondi nel vicinato con la tabella di routing locale -> Poco reattivo. Si aggiornano le tabelle in base ai messaggi ricevuti: se i messaggi rilevano cammini più brevi di quelli noti si stabiliscono nuovi cammini Adatto solo per reti di piccole dimensioni. NB: In Internet si fa Routing per RETE e non per NODO. Routing diretto: se messaggio per la stessa rete non si passa per un router. Routing indiretto: se messaggio verso l’esterno bisogna inserire a livello 2 (MAC) l’indirizzo del router -> sapendo che non è per lui lo
smista verso l’esterno inserendo se stesso come mittente e lasciando invariato il destinatario. Proprietà Routing IP Routing statico
tutto il traffico per una data rete → stesso percorso e non eventuali percorsi alternativi (vedi problemi in caso di limiti di tempo ed urgenze). Tabelle non cambiate troppo spesso. Non multipath in generale.
10
Autonomia
Ogni gateway è autonomo: ogni datagramma da A verso B può seguire un percorso differente rispetto a quello da B verso A i gateway devono cooperare per garantire le due vie di comunicazione nei due sensi. Visibilità
Solo il gateway finale comunica con il destinatario e verifica se l'host esiste ed è operativo: quindi può rimandare al mittente. Indicazioni dei problemi di mancata consegna gli intermediari mandano il datagramma in base alla tabella corrente o alle decisioni di routing attuali. PERCORSO A DEFAULT
Scelta di un gateway cui inviare i messaggi se non si conosce alcuna informazione correttamente. Indirizzamento IP cerca nella tabella locale poi invia il datagramma al gateway di default. Strategia usata da host che servono una piccola quantità di utenti e sono collegati attraverso una sola connessione ad Internet. PERCORSO DIRETTO AD UNO SPECIFICO HOST
Indirizzamento diretto ad un host in modo diretto e specifico, per esigenze particolari con un migliore controllo delle risorse in caso di traffico speciale. Algoritmo function Route_IP_Datagram (datagram, routing_table)
Separazione indirizzo IP destinatario ( Idest) datagramma Valutazione indirizzo IP della rete di destinazione ( Inet) If Inet un indirizzo raggiungibile direttamente then invio diretto del datagramma sulla rete destinataria
(trasformazione indirizzo IP in indirizzo fisico e incapsulamento del datagramma in frame) else if
Idest un host con un cammino proprio
invio del datagramma in base alla tabella else if Inet si può ottenere da una entry nella tabella di routing (tenendo conto di subnet) then si invia il datagramma al prossimo gateway else percorso di default per tutti i restanti datagrammi then
Si tiene conto della sottorete usando la maschera ed Idest. Non competenza delle tabelle -> c’è sempre un router di default.
11
Internet TCP/IP Semantiche di Comunicazione MAY-BE (o BEST-EFFORT) Per limitare i costi ci si basa su un solo invio di ogni informazione -> il messaggio può arrivare o meno Internet è tutto BEST-EFFORT. Rappresentato da IP in cui ogni azione è fatta una volta, senza preoccuparsi di qualità, di affidabilità e di garanzie. (UDP e IP) AT-LEAST-ONCE Si prevedono ritrasmissioni ad intervallo. Il messaggio può arrivare anche più volte a causa della duplicazione dei messaggi dovuti a ritrasmissioni da parte del mittente. Semantica adatta per azioni idempotenti in caso di insuccesso nessuna informazione. Il Cliente di preoccupa della affidabilità. AT-MOST-ONCE Più invii ad intervalli e stato sul server. Cliente e Servitore lavorano in modo coordinato per ottenere garanzie di correttezza e affidabilità. Il messaggio, se arriva, viene considerato al più una volta. La semantica non introduce vincoli sulle azioni applicative. (TCP) EXACTLY-ONCE (ATOMICITÀ) Il messaggio arriva una volta sola oppure il messaggio o è arrivato o non è stato considerato da entrambi -> Semantica molto coordinata sullo stato. Al termine i pari sanno se l'operazione è stata fatta o meno. I pari lavorano entrambi per ottenere il massimo dell'accordo e della reliability. TUTTO o NIENTE Semantica senza durata massima. Se le cose vanno bene il messaggio arriva una volta e una volta sola viene trattato, riconoscendo i duplicati (tutto). Se le cose vanno male il cliente e il servitore sanno se il messaggio è arrivato (e considerato 1 volta sola - tutto) o se non è arrivato. Se il messaggio non è arrivato a uno dei due, il tutto può essere riportato indietro (niente). Completo coordinamento delle azioni, ma durata delle azioni non predicibile. Se uno dei due fallisce, bisogna aspettare che abbia fatto il recovery. Entrambi sanno realmente come è andata (tutto o niente).
Azioni di Gruppo Broadcast NON sono consentiti broadcast a livello globale vista la dimensione del sistema -> per evitare costo inaccettabile Broadcast permessi solo nell'ambito di una rete locale BROADCAST limitato: Limitato perché i router non li fanno passare (rimane sulla stessa rete locale) indipendentemente dall'indirizzo IP. Indirizzo in cui tutti i 32 bit sono a 1 (limited broadcast address). Costo basso. BROADCAST diretto: Verso tutti gli host in una rete specifica. Indirizzo in cui tutti i bit di hostid a 1 (broadcast direttivo o directed broadcast) trasmesso in Internet, arrivato alla destinazione, broadcast.
Multicast Indirizzamenti multicast di Classe D. Indirizzi a cui gli host interessati si possono registrare. Tutti gli host che si sono registrati possono ricevere messaggi e possono mandare messaggi al gruppo di multicast (vedi socket multicast). Problema -> Costo
ARP – Address Resolution Protocol Definito insieme a RARP (non usato). ARP permette di ottenere l’indirizzo MAC di un nodo a partire dal suo indirizzo IP. Questo serve in caso di routing diretto (all’interno della stessa rete locale). È un protocollo costoso perché fa broadcast sulla rete locale. Per questo vengono mantenute delle corrispondenze già note (in tabelle) in cache locali. Quando viene fatta una richiesta ARP sulla rete tutti i nodi della rete vedono la risposta qualificando quindi le tabelle di tutti i nodi (per evitare troppi broadcast). ARP distingue due ruoli nel protocollo, che ogni nodo realizza Attivo richiede l'indirizzo fisico per un pacchetto Esamina la cache per risolvere indirizzo IP localmente, altrimenti esegue una richiesta ARP broadcast
la gestione della richiesta broadcast deve prevedere di non ricevere risposta o riceverla con ritardo
Passivo risponde alle richieste di altri Risponde alle richieste di altri (come server) processando il pacchetto estraendo sia indirizzo IP sia il fisico per pacchetto ARP Se richiesta del proprio indirizzo -> invio risposta Se non risponde -> nodo non connesso -> datagramma buttato via.
1
Livello Data Link (Livello 2 OSI): Ethernet ETHERNET, standard di fatto a livello MAC (Medium Access Control). Formato di un frame con indirizzi a 6 byte o 48 bit con dati di lunghezza variabile da 46 a 1500 byte. Indirizzi a 48 bit per il nodo mittente e destinatario Si introducono sia preamboli, sia delimitatori finali Controllo del frame attuato con controllo CRC
In un frame, per l’invio di 1 solo byte (applicativo oltre il
trasporto) con 1 byte applicativo -> overhead 46 byte (20 IP e 20 TCP/UDP, 5 riempimento)
RARP – Reverse Address Resolution Protocol Protocollo fortemente deprecato. Dato il MAC di un nodo restituisce l’indirizzo IP corrispondente. Serve nel caso in cui ci siano nella rete macchine diskless che non sono quindi in grado di mantenere in memoria la corrispondenza MAC-IP. Quindi deve esserci un Server che è in grado di rispondere alla richiesta. Se sono previsti, spesso ci sono server multipli per RARP: Modello a server attivi Troppi server sovraccaricano il sistema se cercano di rispondere contemporaneamente alla richiesta. Modello a server attivi/passivi soluzioni possibili con gerarchia di server. Per evitare interferenza: Modello dinamico con server differenziati in ascolto: il server primario è il solo a rispondere; gli altri server rispondono solo se arriva una seconda richiesta RARP (anche in gerarchia). Modello statico con server differenziati e ritardi diversi: si prevede che il server primario risponda immediatamente, gli altri con un ritardo calcolato random, con una bassa probabilità di risposta simultanea. È stato uno dei primi casi in cui si è considerata la replicazione di un servizio.
DHCP - Dynamic Host Configuration Protocol Protocollo per la attribuzione dinamica di indirizzi IP per ottenere una configurazione dinamica e con risparmio rispetto ad IP statici. Si basa su due ruoli distinti: clienti e servitori con protocollo di offerta tipo asta (bidding) a più fasi, con iniziativa del cliente: • • • • • •
Broadcast della richiesta di discovery (richiesta di ingresso) (Discover) Offerte da parte dei servitori (con parametri di scelta) (anche non bx) Scelta di una offerta (in broadcast) Conferma della offerta (ACK) Messaggi prima della scadenza (lease). Riconferma dell’indirizzo. Rilascio dell’offerta ( release).
Al contratto viene associata una durata: se durante l’intervallo non si usa, il server può riassegnare l’indirizzo. Il lease permette di confermare l'uso, senza rieseguire il protocollo. DHCP permette l’attribuzione di tutta una serie di parametri di gestione: maschera di rete, sottorete, diritti, ecc. ecc
NAT – Network Address Translation Usato per traslare indirizzi intranet privati in indirizzi IP globali in rete aperta. Serve perché molto spesso si vuole lavorare in reti interne con indirizzi IP propri (interni e privati). Quando la comunicazione deve passare attraverso internet un router NAT attua le traslazione degli indirizzi dall’indirizzo interno ad un indirizzo esterno realmente assegnato alla rete in cui ci si trova. In questo modo però per ogni indirizzo interno bisogna avere un indirizzo esterno. Nelle prime realizzazioni era possibile associare ad un unico indirizzo esterno diversi indirizzi interni (problema con i provider). Questo è reso possibile da un NAT più flessibile, NAT a porte, e che impegna meno risorse esterne (vedi contratti con provider): permette di mappare molti indirizzi interni in un unico indirizzo esterno, distinguendo molteplici indirizzi interni attraverso l’uso di porte diverse di connessione, associate ai diversi indirizzi interni. Questo porta a limitare l’impegno di indirizzi esterni (con molti indirizzi interni associati) ed i costi.
2
ICMP – Internet Control Message Protocol Protocollo di metalivello di gestione e controllo su IP migliorando la qualità best-effort. ICMP usato per coordinare le entità di livello IP. ICMP consente di inviare messaggi di controllo o di errore (datagrammi) al nodo sorgente del messaggio (e solo a questo). Gestisce anche situazioni in cui bisogna controllare la sincronizzazione. Protocollo non connesso -> uso di datagrammi ICMP che si incapsulano in un datagrammi IP -> lavora in-banda. Se viene buttato via questo non viene segnalato altrimenti si genererebbe troppo traffico nella rete (congestione). Formato (Header) • Type identificatore del messaggio • Code informazioni di tipo messaggio • Checksum (16 bit) utilizzato dal relativo algoritmo Se c’è un errore nella parte DATA si inserisce l’header del datagramma che ha
avuto errori. Type: 0 Echo Reply 3 Destinazione irraggiungibile 4 Problemi di congestione ( source quench) 5 Cambio percorso (redirect ) 8 Echo Request 11 Superati i limiti di tempo del datagramma
12 Problemi sui parametri del datagramma 13 Richiesta di timestamp 14 Risposta di timestamp 15 Richiesta di Address mask 16 Risposta di Address mask Echo Request e Echo Reply consentono di fare il servizio di Ping.
Code: intero dipendente dai valori di TYPE. 0 Rete irraggiungibile 1 Host irraggiungibile 2 Protocollo irraggiungibile 3 Porta irraggiungibile
4 Frammentazione necessaria 5 Errore nel percorso sorgente (source route fail) 6 Rete di destinazione sconosciuta
Comando ping per stimare il RoundTrip Time o RTT Si mandano echo request al nodo e attesa di echo reply. Si possono variare le dimensioni dei dati ed il numero di invii, secondo le diverse necessità di gestione Comando traceroute (o tracert) per visualizzare il percorso da un nodo fino ad un altro nodo della rete Si mandano messaggi con TimeToLive crescente. Il nodo che riceve il datagramma con TTL=0 lo scarta e manda un messaggio ICMP al mittente. Ogni perdita forza un messaggio ICMP catturato dal mittente. Così si può ricostruire tutto il percorso. Funziona bene se le tabelle di routing non cambiano spesso.
UDP – User Datagram Protocol UDP protocollo di trasporto (Livello 4 OSI) molto semplice, best-effort e a basso costo. UDP deve distinguere tra più processi in esecuzione su un dato nodo connesso alla rete, processi identificati con numero di porta UDP. Si appoggia a IP per consegnare i datagrammi. Indirizzo: indirizzo IP + numero di porta (16 bit) Header Composto da due parole da 32 bit. Porta sorgente e porta destinataria, checksum e lunghezza del messaggio (necessaria per definire il payload). Datagramma al massimo 64kb. Uno user datagram (UDP) è del tutto contenuto nell'area dati del datagramma IP, senza nessuna frammentazione. Se supera la dimensione massima -> tronca. Overhead molto limitato. Per le porte: C’è un’unica driver UDP che prende decisioni di multiplexing/demultiplexing sulle porte.
Multiplexing: messaggi da più processi applicativi paralleli con un solo servizio IP. Demultiplexing: lo stesso messaggio recapitato alla porta corretta. UDP/TCP adottano soluzione ibrida: alcuni numeri di porta a priori (well known port) e gli altri assegnati dinamicamente. Porte note 0 Riservato 37 time 7 echo 69 tftp (trivial file transfer protocol) 9 discard 111 Sun RPC protocol 11 users 513 who (demone di rwho) 13 daytime 514 system log
3
TCP – Entità e connessioni TCP permette la connessione end-to-end tra più processi di nodi distinti, creando l'astrazione connessione come coppia di endpoint Un endpoint è definito come coppia di interi {host, port} con host l'indirizzo IP dell'host, e port della porta TCP La connessione è la quadrupla {host1, port1, host2, port2} Può esistere una sola connessione per quadrupla La driver TCP fa multiplexing/demultiplexing sulle porte. Porta Protocollo Descrizione 20 FTP-DATA File Transfer Protocol (dati) 21 FTP File Transfer Protocol 23 TELNET Terminale Remoto 25 SMTP Protocollo di posta elettronica 80 HTTP Protocollo web 119 NNTP Protocollo news
ARQ - Automatic Repeat reQuest Protocollo di ritrasmissione automatica. Se non si riceve un ACK relativo ad una richiesta si ritrasmette (Semantica At-Least-Once). Protocollo fortemente sincrono bloccante (con stop and wait).
Continuous Requests Protocollo più complesso rispetto al caso ARQ Non attesa in modo sincrono della ricezione conferma (ACK) ma si mandano messaggi in modo ripetuto. Il mittente manda messaggi che sono mantenuti fino a saturare la memoria disponibile (finestra buffer) e sono scartati solo alla conferma. Il mittente scorre la finestra in caso di conferma (all'acknowledgement). Attesa del mittente solo a finestra piena. La dimensione della finestra è imposta dal ricevente. Variazione imposta dal ricevente (se a 0 attesa finchè non si libera). In caso di Errore: SELECTIVE RETRANSMISSION attesa dell’esito dei messaggi tenendo conto degli ack ricevuti e anche ack negativi (dovuti al time-out del ricevente) e ritrasmissione di quelli persi. GO-BACK-N attesa di ack e ritrasmissione (solo con time-out al mittente) e tenendo conto di ack del ricevente (che salta i non ricevuti); il mittente scarta i messaggi successivi non in sequenza e li rimanda tutti al ricevente go-back confonde messaggi non in ordine con perdite (TCP usa GO-BACK-N ottimizzato e ack cumulativi). Nell’implementazione TCP (nel ricevente) i messaggi già ricevuti non vengono sostituiti. Un ack può confermare anche i messaggi precedenti. Nei protocolli continuous requests, ogni direzione di trasmissione usa una finestra scorrevole (sliding window) per la gestione della memoria di bufferizzazione. La decisione della dimensione del buffer è sempre del ricevente che deve allocarla e mantenerla per i messaggi. Gli slot non sono mai della stessa dimensione.
TCP - Transmission Control Protocol TCP fornisce un servizio di trasmissione dati affidabile basato su • Reliable stream full duplex • Connessione o canale virtuale bidirezionale Due stream di byte. Su ognuno semantica at-most-once. Lo stream, ossia il flusso, è costituito di dati in ordine preciso e non alterabile. • Flusso di dati non strutturato (byte stream) e dati normali • Dati prioritari in banda limitata (1 byte) La connessione TCP NON impegna i nodi intermedi si usano solo le risorse dei nodi degli end-user. Nessun cammino statico. Il protocollo TCP si basa su alcuni principi e vincoli da rispettare: • Formato dei dati trasmessi (segmenti con header fissato) • Possibilità di dati urgenti • Regole per la bufferizzazione e l'invio degli acknowledgement (sliding window) e relativo formato • Possibilità di comporre messaggi e decomporre in segmenti (default 536kb). Decisione del protocollo. • Meccanismi di de/multiplexing (vedi UDP) attraverso il concetto di porta per distinguere più processi su uno stesso host La realizzazione si basa sulla implementazione della connessione e sulla comunicazione, permettendo servizi che devono occuparsi di 1. Stabilire la connessione (Prologo) 2. Scambiare dati sulla connessione 3. Chiudere la connessione (Epilogo)
4
Header 5 parole da 32 bit (4 byte). (IP è nell’header del Datagramma) Sequence Number: Numero che indica la posizione precisa nel flusso del byte contenuto nel segmento. Acknowledgement Number: Indica lo stato di ricezione del mittente, quanto è stato ricevuto del flusso. Viene inviato sempre. (Piggybacking: Sfrutta la trasmissione per fare controllo.) Checksum: Complemento a 1 per il controllo. HLEN: Header Length, tipicamente è 5, ma che può essere maggiore perché possono esserci Opzioni. Window: indicazione in byte della dimensione della finestra di ricezione. CODE BIT (6bit a 0 o 1): ACK: se a 1 l’acknowledgement number e valido. SYN: bit per stabilire una connessione. FIN: bit per chiudere una connessione. RST: Se a 1, ci sono stati problemi nella connessione (o di qualità) quindi si ristabilisce. URG: Se a 1 indica che il flusso contiene un dato urgente e viene letto l’urgent pointer. Il campo urgent pointer dice la distanza dalla posizione corrente nel flusso. Banda di 1 byte -> può essere sovrascritto da un URG successivo. Se viene segnalato un dato urgente da livello applicativo sul flusso -> tutti gli header portano la segnalazione del dato urgente. PUSH: Se a 1, il segmento viene mandato immediatamente senza bufferizzazione. Anche se in realtà sono le driver a decidere.
TCP – Comunicazione TCP può spezzare i messaggi applicativi in segmenti di dimensione variabile, e tende a frammentare messaggi in segmenti • Né troppo corti: grosso overhead di trasmissione • Né troppo lunghi: frammentazione a livello di IP e possibili perdite TCP usa CONTINUOUS REQUEST per efficienza e affidabilità I messaggi prevedono ack, che essendoci traffico nei due sensi, gli ack sono inseriti sul traffico in direzione opposta (piggybacking) USO di finestra scorrevole, espressa in byte, determinata e decisa dal ricevente e comunicata per ogni invio di segmento. TCP – Ritrasmissione TCP usa GO BACK-N, in caso di non ricezione di un segmento • il ricevente può scartare quelli successivi e attendere il segmento mancante • il mittente deve rimandare i segmenti da quello che manca • reinvio anche ripetuto fino ad una eccezione (fallimento) • il ricevente deve favorire il reinvio di segmenti mancanti In realtà il ricevente ottimizza e non scarta immediatamente i segmenti fuori ordine (ma li mantiene se può per integrarli). DOPO quanto tempo si ritrasmette, QUANTE VOLTE si esegue le ritrasmissione, COME si frammentano i segmenti decide tutto la driver. Il protocollo a stream può rimandare parti del flusso ossia segmenti con dimensioni diverse senza garanzie di lunghezze predefinite o stabili. TCP – Conferme TCP conferma con ack cumulativi (numero di ack non uguale al numero di messaggi ricevuti) Un ack specificato del ricevente porta l'indicazione di tutto ciò che è stato ricevuto nello stream fino al momento dell'ack. In caso di perdita, si continua a mandare ack per l'ultimo ricevuto.
5
TCP – Fasi di Operatività Fase iniziale - three-way handshaking In cui si stabiliscono una serie di parametri operativi per la connessione e si prepara l'avvio Fase di comunicazione – transitorio e regime Transitorio iniziale: si comincia a lavorare in fase esplorativa (per “scaldare” il canale) Regime in varie condizioni operative diverse. Si devono considerare situazioni di congestione individuando o prevenendo i colli di bottiglia fino a ristabilire una situazione normale o fino ad un abort della connessione Fase finale – chiusura mono e bidirezionale (a quattro vie) Chiusura manifestata da uno dei due pari e accettata dall'altro. Operatività con canale monodirezionale di dati, ma con messaggi di controllo in entrambe le direzioni. TCP – Fase Iniziale – Three-way handshake Fase solo di gestione. Costituisce la negoziazione iniziale fra le due parti. 3 messaggi (senza dati) scambiati. 1. A invia a B il segmento con SYN e richiede la connessione (SYN nell'header del segmento e X valore iniziale del flusso scelto da A) 2. B riceve il segmento SYN e ne invia uno identico ad A con ACK (anche del valore mandato da A, X+1) anche SYN con Y valore scelto da B per il suo verso. 3. A riceve il segmento SYN ed ACK e conferma la ricezione a B attraverso un ACK a sua volta (Y+1) Sono 3 perché servono a dimensionare finestre e time-out. X e Y sono numeri casuali perché se si partisse da 0 potrebbe interferire con altre richieste di connessione. Bidding (senza rifiuto). Se si dovesse perdere un messaggio si reinvia con intervalli di time-out crescenti e dopo si chiude. In fase iniziale si possono negoziare altre opzioni: • Accordo sul segmento medio o MSS (Maximum Segment Size) (default 536 byte) • Fattore di scala della finestra (max 64kb perché espresso in 16bit) • Richiesta di tempo e risposta per il coordinamento degli orologi Tutta la fase iniziale è legata alla connect dalla parte del cliente. TCP – Fase Finale – Chiusura in 4 fasi Si prevede una semplice operazione di chiusura graceful. Chiusura monodirezionale di output ossia definitiva per un solo verso (il verso di autorità) senza perdita dei messaggi in trasferimento e di quelli in arrivo. 1. A invia segmento FIN in ordine dopo l’invio dei dati precedenti TCP aspetta a dare corso alla chiusura, ma invia da A a B solo ack. 2. B invia L’ACK relativo al FIN. Si mandano altri dati da B ad A. 3. Al termine del traffico applicativo da B ad A, B invia ad A il segmento FIN che informa della disponibilità a chiudere la connessione 4. L'ultimo passo conferma (ACK) da A a B della ricezione del segmento FIN e la chiusura totale della connessione TCP – Fase Transitoria Le connessioni in TCP, nella fase transitoria iniziale vengono “scaldate”. Cioè a la operatività sulla connessione avviene solo dopo avere
cominciato in modo graceful e tentando di andare verso la situazione di regime nel modo migliore possibile. Consente ai router di sostenere le bande necessarie a realizzare la connettività. TCP – A Regime Nella fase iniziale si sono dimensionati i time- out. Durante l’interazione potrebbe cambiare qualcosa e quindi potrebbero cambiare anche di molto. TCP ricalcola dinamicamente la distanza in tempo utilizzando solo i messaggi confermati (con ACK). Ricalcolo del Time-out in base a una formula del tipo (Karn) Timeout = α * Intervallo precedente + β * Intervallo corrente
Cioè si tiene conto della storia e si aggiunge un po’ di dinamica (con i fattori alfa e beta)
Non viene fatta nessuna ritrasmissione -> time-out ricalcolato solo in caso di successo.
6
TCP – Controllo di Flusso Il controllo di flusso è fondamentale in Internet in cui ci sono connessioni con macchine molto diverse fra loro. Sono meccanismi fondamentali di coordinamento: • la finestra La dimensione della finestra viene inviata per ogni segmento e comunica al pari quali siano le esigenze di memoria della connessione. Una finestra a 0 significa di non inviare alcune segmento. Ogni pari comunica all’altro la propria situazione con la finestra • la dimensione preferenziale dei segmenti da inviare attesa di dati prima di inviarli fino ad avere un segmento che sia conveniente inviare (Maximum Segment Size come opzione TCP). Si deve evitare di avere trasmissioni di messaggi corti: Silly window (finestre limitate) e messaggi brevi. Algoritmo di Nagle: si ammette di avere pendente senza ack al più un solo messaggio corto - retroazione automatica per non inviare messaggi corti in eccesso. Problemi ad esempio in telnet: movimenti del mouse (messaggi molto c orti) -> disabilitato. TCP – Congestione Per congestione di intende la situazione in cui non si riescono più a consegnare dati in tempi utili (rispetto alla operatività corrente). uno stato che può essere non solo dipendente dai soli endpoint della connessione stessa, ma anche da una più ampia situazione dell’intero sistema. Può presentarsi in due casi: è stato forzato troppo il cammino della connessione e abbiamo congestionato solo le nostre risorse locali Tutti i router sono con buffer pieni e nessuno scambio può più avvenire, fino alla de-congestione. Anche se i router possono segnalare buffer pieni. Per il secondo caso si può agire con meccanismi di Avoidance (azione preventiva) o con azioni di Recovery (azione reattiva). L’identificazione della congestione avviene dopo un time out che scatta in modo continuo. In questo modo si assume che il destinatario non sia raggiungibile e che la congestione sia in atto.
Come azione di Recovery si devono attuare azioni locali per evitare di aggravare il problema: In modo unilaterale il mittente dimezza la finestra di invio e raddoppia il time-out (finchè non arriva a 0) Al termine della congestione, per ritornare a regime, si riparte con un transitorio con finestra piccola (slow start) Come azione di Avoidance si attua lo Slow Start in cui variazioni vengono fatte in modo dolce. Lo Slow Start è il transitorio sulla finestra del mittente per arrivare da una situazione iniziale fredda (senza comunicazione) ad una comunicazione a regime calda (diversa banda) in modo graduale (dolce). In questo meccanismo si considerano tre variabili: La cwnd (congestion window): finestra corrente lato mittente (variabile). La rwnd (receiving window): finestra segnalata e dettata dal ricevente. ssthresh (Slow Start Threshold): valore variabile, soglia di slow start.
7
Il controllo di congestione lavora in due fasi distinte di operatività 1. Slow start (se cwnd < ssthresh) cwnd viene incrementato (a partire da 1). La crescita avviene in modo esponenziale fino allo ssthreshold (viene raddoppiato) Poi diventa lineare (fase di congestion avoidance) Cresce fino alla dimensione totale della finestra (rwnd) o fino a time-out. 2. Congestion avoidance (se cwnd >= ssthresh) In caso di congestione avvenuta (time-out), si ridimensiona tutto e si riparte in modo esplorativo (slow start) L’ssthreshold viene dimezzato.
Ricapitolando: Slow Start - Si inizia con un segmento nella finestra di congestione, e si raddoppia (exponential backoff ) appena arriva un ACK. Quando la finestra di congestione raggiunge quella di ricezione, siamo a regime e si incrementa/decrementa di unità alla volta (fase lineare) fino ad eventuali situazioni di congestione.
Strategie tipiche TCP
Ricalcolo del time-out in modo dinamico Il time out corrente viene tarato rispetto a quanto calcolato come media con la stima del time-out precedente. Exponential backoff In caso di ritrasmissione, il time-out raddoppia, fino ad un tempo massimo (ad es. 4'), poi si chiude la connessione. Silly window Per evitare di lavorare un byte alla volta, non si annunciano finestre di dimensione troppo piccole (MSS/2) a parte la finestra chiusa (0 per blocca trasmissioni pari) Limiti al time-wait Per limitare la durata delle risorse per la connessione. Ricordiamo che la memoria sulla porta dovrebbe essere mantenuta per tempi necessari per smaltire tutto il contenuto del buffer ma non troppo superiori a quelli. (in caso di close che mantengono la memoria in uscita fino a consegna) Long fat pipes Per mantenere piene le pipe a banda elevata (fornendo indicazioni di buffer superiori a quelli di utente e bufferizzando a livello di supporto).
8
Socket in Java Progetto C/S Le socket rappresentano il terminale locale (end-point) di un canale di comunicazione bidirezionale (da e per l’esterno). In Java (standard) si risolve il problema della comunicazione tra macchine distinte, diverse e fortemente eterogenee. Le Socket possono realizzare due tipi di comunicazione: •
•
Con connessione, in cui viene stabilita una connessione tra Client e Server (esempio, il sistema telefonico) (socket STREAM) o
Protocollo Internet TCP
o
Classe Socket, per socket lato Client
o
Classe ServerSocket , per socket lato Server
Senza connessione, in cui non c’è connessione e i messaggi vengono recapitati uno indipendentemente dall’altro (esempio, il sistema postale) (socket DATAGRAM) o
Protocollo Internet UDP
o
Classe DatagramSocket , per socket (C/S)
Sistema di nomi Necessità di un sistema di identificazione degli enti in gioco. Per risolvere il problema dell’identific azione reciproca dei processi (Client e Server nella rete ad ogni processo deve essere associato un nome globale: visibile in modo univoco, non ambiguo e semplice. Questo viene risolto dai livelli bassi di protocollo (trasposto e rete). Un nodo è identificato univocamente da: •
•
Indirizzo IP (4 byte / 32 bit) -> livello IP (della macchina) o
Identificativo della macchina nella rete
o
Esempio 137.204.57.186
Porta (numero intero di 16 bit) -> astrazione in TCP e UDP o
Porta all’interno della macchina a cui deve essere collegata la socket
o
4 cifre esadecimali XXXXh (valori tra 1 e 65535). Le prime 1024 sono riservate (well-known port)
Uso di questo NOME GLOBALE che rappresenta l’end-point di un canale di comunicazione. Per raggiungere una risorsa con NOME LOCALE: un processo (o più) si lega a una porta per ricevere o spedire dei messaggi. In questo modo è possibile identificare un processo senza conoscere il suo PID locale.
Server Sequenziali e Paralleli in Java Tipicamente una socket comprende una coda di ingresso (buffer). Server Sequenziali Server che gestiscono una richiesta alla volta (con connessione o meno)
Con Connessione (uso TCP) Servizi che devono garantire affidabilità, limitando lo stato. Overhead per controllo connessione. Necessaria quando i dati da scambiare sono molti per questioni di ordine e affidabilità (che tutto arrivi sicuramente).
Senza connessione (uso UDP) Servizi senza stato e poco soggetti a guasti
Server Paralleli Server concorrente multiprocesso con più richieste alla volta. Uso di processi multipli, con un master server (main) che genera processi interni (thread) per ogni servizio. In Java è di difficile realizzazione un server concorrente monoprocesso.
Socket Datagram Le socket datagram permettono a due thread diversi di scambiarsi messaggi senza stabilire una connessione tra i thread coinvolti. Classe java.net.DatagramSocket . Modello non affidabile. Uno dei costruttori presenta la seguente interfaccia DatagramSocket ( InetAddress localaddress , int localport) throws SocketException; Una volta invocato il costruttore la socket è pronta a realizzare uno scambio di messaggi con un’altra socket.
Lo scambio di messaggi con socket avviene tramite meccanismi primitivi di comunicazione. Su una istanza di DatagramSocket si fanno azioni di:
void send(DatagramPacket p);
void receive(DatagramPacket p);
Le due primitive sono reali operazioni di comuncazione La send invia il messaggio (asincrona con la receive) consegnando solamente il messaggio al livello sottostante (kernel) che si occuperà dell’invio. La receive invece ha una semantica sinctona (localmente) per il ricevente (bloccante localmente): basta ricevere un messaggio per sbloccare la receive.
1
Modello di comunicazione Le socket datagram per lo scambio di messaggi devono essere state inizializzate correttamente e devono conoscersi. Il mittente deve specificare nel messaggio un ricevente. Si devono specificare informazioni di tipo applicativo e di controllo (messaggio e inirizzo IP e porta del destinatario). Quando il pacchetto arriva al destinatario le driver inseriscono nelle informazioni di controllo IP e porta del mittente. Lo stesso datagramma viene usato per la richiesta e la risposta. Ovviamente nessuna garanzia di consegna con qualità a causa del protocollo di supporto usato (UDP e IP).
Classi accessorie DatagramPacket( byte [] buf, // array di byte dati int offset, // indirizzo inizio int length, // lunghezza dati InetAddress address, int port); // numero IP e porta Classe per preparare e usare datagrammi. Contiene una parte relativa ai dati e una relativa al controllo. Fornisce anche molte funzioni di utilitù come getPort, getData o getAddress . Parte dati -> specifica un array di byte da/su cui scrivere e non indicazioni di comunicazione con diversi costruttori Parte di controllo -> InetAddress e interi per la porta InetAddress è una classe che serve a rappresentare gli indirizzi IP (presenta solo metodi pubblici statici):
public static InetAddress getByName (String hostname );
fornisce un oggetto InetAddress per l’host specificato (null def. locale)
public static InetAddress[] getAllByName (String hostname);
fornisce un arra di oggetti InetAddress per pi indirizzi IP sullo stesso nome logico
public static InetAddress getLocalHost ();
fornisce InetAddress per macchina locale sock.send(DatagramPacket p) in invio bisogna preparare tutte le opportune strutture dati che servono a contenere la parte
dati del datagramma e l’area relativa alle informazioni di controllo sul ricevente (fornite dal mittente del pacchetto. sock.receive(DatagramPacket p) in ricezione si deve avere preparato tutto ciò che serve a ricevere tutte le informazioni (sia
dati che controllo). Uno stesso pacchetto può essere riutilizzato.
Esempio Creazione socket DatagramSocket socket = new DatagramSocket(); Parte mittente di invio... Preparazione informazione da inviare e invio byte[] buf = {'C','i','a','o'}; InetAddress addr = InetAddress.getByName("137.204.59.72"); int port = 1900; DatagramPacket packet = new DatagramPacket(buf, buf.length, addr, port); socket.send(packet); // invio immediato In ricezione Creazione socket DatagramSocket socket = new DatagramSocket(); Parte ricevente di comunicazione: Preparazione, attesa, e ricezione int recport; InetAddress recaddress; byte[] res = new byte[200]; DatagramPacket packet = new DatagramPacket(res, res.length, recaddress, recport); packet.setData(res); // riaggancio della struttura dati socket.receive(packet); // ricezione con attesa sincrona // estrazione delle informazione dal datagramma recport = packet.getPort(); recaddress = packet.getAddress(); res = packet.getData(); // uso delle informazioni ...
2
Comunicazione Multicast MulticastSocket(int multicastport); Socket legate a indirizzi IP di gruppo di classe D (necessario per riferimento) attraverso un gruppo di multicast su cui ricevere messaggi (IP e porta). I nodi che devono ricevere devono prepararsi alla ricezione considerato che la comunicazione non è più punto-punto. Il gruppo viene creato ed alimentato da ingressi, come registrazione o manifestazione di interesse, f ino all’uscita (join e leave). In java si può essere più selettivi usando le porte: il gruppo è composto solo da chi ha usato la stessa porta -> Si possono avere più gruppi sullo stesso indirizzo IP di classe D, distinti dalla porta. Preparazione gruppo: IP classe D e porta libera InetAddress gruppo = InetAddress.getByName("229.5.6.7"); MulticastSocket s = new MulticastSocket(6666); Operazioni di ingresso/uscita dal gruppo (per ricevere) // unisciti al gruppo ... e esci dal gruppo s.joinGroup(gruppo); s.leaveGroup(gruppo); // il sistema operativo può tenere conto della porta per selezionare i messaggi
Opzioni Socket La ricezione da socket (es., receive()) è sincrona bloccante
SetSoTimeout (int timeout) throws …
Questa opzione definisce un timeout in msec, dopo il quale la operazione termina (e viene lanciata una eccezione da gestire). Se timeout a zero, nessuna sospensione.
SetSendBufferSize (int size) throws …
Il buffer di invio e ricezione della driver può essere variato
SetReceiveBufferSize (int size) throws …
SetReuseAddress() Si possono collegare più processi ad un certo indirizzo fisico. Sono previste le get corrispondenti.
Socket a Stream Nel caso delle socket Stream tra cliente e servitore di interpone una terza entità: la Connessione. La comunicazione avviene con semantica at-most-once: comunicazione bidirezionale, affidabile (garanzie forti di QoS), con dati (byte) consegnati in sequenza una sola volta. La connessione tra processi client e server è definita univocamente da una quadrupla e dal protocollo (non dai processi) In questo modo basta cambiare anche solo una porta per ottenere una nuova connessione. Protocollo utilizzato TCP+IP. TCP protocollo di trasporto (livello 4 OSI) che fornisce l’astrazione della porta e IP, protocollo di rete (Livello 3 OSI) per l’identificazione del nodo. In Java per Client e Server esistono due tipi distinti di Socket (classi distinte per ruoli di Cliente e Servitore) e sono necessarie entrambe per realizzare una comunicazione. Le classi java.net.Socket e java.net.ServerSocket. Si nascondono i dettagli realizzativi dei protocolli, ad esempio nei costruttori delle classi. La classe Socket consente di creare una socket “attiva” connessa stream (TCP) per il collegamento di un client a un server.
I costruttori della classe creano la socket, la legano a una porta locale e la connettono a una porta di una macchina remota su cui sta il server. La connessione permette poi una comunicazione bidirezionale (full duplex). La creazione della socket produce in modo atomico anche la connessione al server corrispondente (deve essere presente).
Socket Stream – Client Costruttori
public Socket (InetAddress remoteHost , int remotePort ) throws IOException;
Crea una socket stream cliente e la collega alla porta specificata della macchina all’indirizzo IP dato (equivale in Unix a: socket, bind, connect)
public Socket (String remoteHost, int remotePort )throws…
Crea una socket stream cliente e la collega alla porta specificata della macchina di nome logico remoteHost
public Socket (InetAddress remoteHost , int remotePort , InetAddress localHost , int
localPort )throws… Crea una socket stream cliente e la collega sia a una porta della macchina locale (se localPort vale zero, il numero di porta è scelto automaticamente dal sistema) sia a una porta della macchina remota.
3
Gestione APERTURA ottenuta con il costruttore in modo implicito. La creazione con successo di una socket a stream produce una connessione bidirezionale a byte (stream) tra i due processi interagenti e impegna risorse sui nodi e tra i processi. Ha un costo anche per il destinatario. CHIUSURA come operazione necessaria per non impegnare troppe risorse di sistema. Le risorse sono le connessioni: costa definirle e crearle, così si devono gestirle al meglio, mantenerle e distruggerle. Si devono mantenere le sole connessioni necessarie e limitare le aperture contemporanee di sessioni chiudendo quelle non utilizzate. Il metodo close() chiude l’oggetto socket e disconnette il Client dal Server public synchronized void close() throws SocketException; Viene eseguita in modo atomico (in mutua esclusione) perché possono esserci più thread che condividono una stessa socket.
Supporto Per informazioni sulle socket si possono utilizzare i metodi aggiuntivi
public InetAddress getInetAddress(); // remote
Restituisce l’indirizzo del nodo remoto a cui socket è connessa
public InetAddress getLocalAddress(); // local
Restituisce l’indirizzo della macchina locale
public int getPort(); // remote port
Restituisce il numero di porta sul nodo remoto cui socket è connessa
public int getLocalPort(); // local
Restituisce il numero di porta locale a cui la socket è legata Esempio: int porta = oggettoSocket.getPort(); Si possono ottenere dinamicamente (runtime) informazioni sulle connessioni correnti delle socket usate. Quando si apre una connessione si aprono sempre due flussi di byte (leggere/scrivere dalla/sulla socket). Lettura o scrittura da/su una socket dopo avere qualificato le risorse stream della socket come Java stream
public InputStream getInputStream()
public OutputStream getOutputStream()
I due metodi restituiscono un oggetto stream che incapsula il canale di comunicazione (di classi InputStream e OutputStream) Attraverso gli stream (generici di byte) si possono spedire/ricevere solo byte, senza nessuna formattazione in messaggi (vedi classi) Naturalmente, i byte arrivano ordinati e non duplicati (non possono arrivare byte successivi, senza che arrivino i precedenti); i dati arrivano al più una volta (at-most-once). In caso di errore? Nessuna conoscenza. Altri oggetti stream Java possono incapsulare gli stream socket, per fornire funzionalità di più alto livello (ad es., DataInputStream). DataOutputStream e DataInputStream offrono una serie di metodi per l’invio e la ricezione di tipi primitivi Java. Uso tipico: realizzazione di protocolli fra Client e Server scritti in linguaggio Java (con scambio di oggetti Java): nel corso vengono usati per la realizzazione di applicazioni C/S in Java. DataOutputStream String void writeUTF(String s) char void writeChar(char c) int void writeInt(int i) float void writeFloat(float f)
DataInputStream String readUTF() char readCHar() int readInt() float readFloat()
Esempio Client di echo (il Server Unix è sulla porta nota 7 ) progetto di filtro try { oggSocket = new Socket (hostname , 7); /* input ed output sugli endpoint della connessione via socket */ out = new PrintWriter (oggSocket .getOutputStream (),true); in = new BufferedReader (new InputStreamReader(oggSocket.getIntputStream() );
userInput = new BufferedReader (new InputStreamReader(System.in)); /* ciclo lettura fino a fine file */ while((oggLine = userInput.readLine()) != null) { out.println(oggLine); System.out.println( in.readLine()); }
oggSocket.close(); } catch (IOException e) { System.err.println(e);}
Per ogni ciclo si legge da standard input, si scrive sulla socket out e si attende da socket in la risposta di echo.
4
Socket Stream – Server Il Server ha un ruolo diverso: deve avere la possibilità di accodare le richieste (fase iniziale) e questo viene realizzato attraverso la ServerSocket che definisce un tipo diverso di Socket capace di accettare richieste di connessione provenienti da diversi Client. più richieste di connessione pendenti allo stesso tempo e più connessioni aperte contemporaneamente. Si deve definire anche la lunghezza della coda in cui vengono messe le richieste di connessione non ancora accettate dal server. Al momento della creazione si effettuano implicitamente le operazioni più elementari visibili in UNIX, come socket, bind e listen La connessione richiede di essere stabilita su iniziativa del server (ottenuta tramite primitiva di comunicazione accept). Obiettivo della accept, lato server, è restituire un normale oggetto Socket nel server per la specifica connessione e trasmissione dati.
Costruttori Sulle socket dalla parte server:
public ServerSocket (int localPort ) throws IOException, BindException;
Crea una socket in ascolto sulla porta specificata
public ServerSocket (int localPort, int count)
Crea una socket in ascolto sulla porta specificata con una coda di lunghezza count Il server gioca un ruolo “passivo”: deve attivare la coda delle possibili richieste ed aspettare i clienti ( attivi: effettuano la richiesta). Il
server comincia a decidere con la introduzione volontaria della primitiva di accettazione esplicita. Le richieste accodate non sono servite automaticamente ed è necessaria una API che esprima la volontà di servizio.
Accept Il Server si deve mettere in attesa di nuove richieste di connessione chiamando la primitiva accept() public Socket accept() throws IOException; L’invocazione di accept blocca il Server fino all’arrivo di almeno una richiesta di connessione.
La accept restituisce un oggetto della classe Socket su cui avviene la comunicazione vera di byte tra Client e Server. Client e Server dopo la connessione sono omogenei: si comportano esattamente allo stesso modo. Quando arriva una richiesta, la accept crea una nuova socket per la connessione di trasporto già creata con il Client: la nuova Socket restituita dalla accept rappresenta lo stream reale con il cliente. La chiamata di accept è sospensiva, in attesa di richieste di connessione:
Se non ci sono ulteriori richieste, il servitore si blocca in attesa
Se c’è almeno una richiesta, si sblocca la primitiva e si crea la connessione per questa (la richiesta è consumata)
NB: Tutte le socket su un server insistono sulla stessa (unica) porta.
Supporto La trasmissione dei dati avviene con i metodi visti per il lato Client in modo del tutto indifferente in uno o l'altro verso della connessione i due endpoint sono del tutto omogenei (come nel protocollo TCP) Informazioni sulle socket connesse come nel cliente:
public InetAddress getInetAddress(); // remote
Restituisce l’indirizzo del nodo remoto a cui socket è connessa
public InetAddress getLocalAddress(); // local
Restituisce l’indirizzo della macchina locale
public int getPort(); // remote port
Restituisce il numero di porta sul nodo remoto cui socket è connessa
public int getLocalPort(); // local
Restituisce il numero di porta locale a cui la socket è legata
Esempio Server daytime (Server Unix su porta 13) progetto di demone try { oggServer = new ServerSocket ( portaDaytime); while (true) /* il server alla connessione invia la data al cliente */ { oggConnessione = oggServer.accept (); //attesa di connessioni (), true); out = new PrintWriter (oggConnessione .getOutputStream Date now = new Date(); // produce la data e la invia out. write(now.toString()+ "\r\n"); oggConnessione.close (); // chiude la connessione e il servizio } } catch (IOException e) { oggServer.close (); oggConnessione.close (); System.err.println(e);} Ad ogni cliente il server sequenziale manda la data e chiude tutto
5
Server Parallelo Alla accettazione delle richieste si genera un nuovo thread responsabile del servizio (eredita la connessione nuova e la chiude al termine dell’operazione). Il servitore in questo modo può tornare
immediatamente ad aspettare nuove richieste e servire nuove richieste. Quindi di tratta di un server parallelo multiprocesso con connessione. Limite al numero di socket: La socket è come un file, ad ogni apertura -> nuovo file descriptor -> Tabella dei f ile aperti, quindi un limite abbastanza largo.
Chiusura di una Socket Le socket in Java impegnano non solo il loro livello applicativo, ma anche una serie di risorse di sistema che sono collegate e necessarie per la operatività fino alla close(). La chiusura è quindi necessaria sempre per dichiarare al sistema la non necessità di mantenere risorse non più in uso. Tipicamente la close() è molto veloce (passante) a livello applicativo. Ai livelli sottostanti non è la stessa cosa. In caso di socket connessa chiusa, la memoria di out viene mantenuta per continuare a spedire informazioni da inviare al pari mentre quella in ingresso viene buttata via. Questo potrebbe richiedere del tempo (anche molto). La chiusura è fatta su iniziativa di uno dei processi affacciati quando vuole ed ha impatto anche sull’altro. Si hanno anche primitive differenziate per la chiusura per un verso solo, shutdownInput() e shutdownOutput() La primitiva più usata per chiusure responsabili è la shutdownOutput() per cui si chiude la direzione di responsabilità. In caso di socket connessa in shutdown, la memoria di out viene mantenuta per spedire informazioni al pari , la in è soggetta all’altro . Non si faranno mai di shutdown di input perché praticamente in una connessione bidirezionale ognuno è padrone della propria uscita ma non dell’ingresso (che dipende dall’altro responsabile della chiusura).
Opzioni Opzioni delle Socket per cambiare il comportamento
SetSoLinger (boolean on, int linger ) //Linger = stare intorno Dopo la close, il sistema tenta di consegnare i pacchetti ancora in attesa di spedizione . Questa opzione permette di scartare i pacchetti in attesa dopo un intervallo di linger in sec. La parte di out deve durare “linger” secondi dopo la close che, quindi, durerà massimo “linger” secondi.
SetTcpNoDelay (boolean on) throws ... Il pacchetto è inviato immediatamente, senza bufferizzare
SetKeepAlive (boolean on) throws... Abilita, disabilita la opzione di keepalive. Vengono mandati dei messaggi di keepalive quando non succede niente nella connessione.
Le opzioni sono disponibili nella interfaccia SocketOptions che prevede anche tutte le get corrispondenti.
6
RMI (Remote Method Invocation) RMI introduce la possibilità di richiedere esecuzione di metodi remoti in JAVA integrando il tutto con il paradigma Object Oriented. È un insieme di strumenti, politiche e meccanismi che permettono ad un’applicazione Java in esecuzione su una macchina di invocare i metodi di un oggetto di una applicazione Java in esecuzione su una macchina remota.
Localmente viene creato solo il riferimento ad un oggetto remoto, che è effettivamente attivo su un nodo remoto. Un programma cliente invoca i metodi attraverso questo riferimento locale mantenuto in una variabile interfaccia. La variabile locale, essendo di una certa, definita, interfaccia può contenere istanze di classi che la implementano (anche diverse) -> CAST per recuperare l’istanza giusta. Semantica per riferimento tipica dei linguaggi ad oggetti: una classe può contenere riferimenti ad altre classi (oltre a tipi primitivi). Questa, quando viene riferita, viene considerato tutto il grafo di oggetti legati alla classe. Quindi quando, ad esempio, bisogna esternalizzare la classe si deve considerare tutto il grafo e non solo il primo livello. L’interfaccia rappresenta un contratto di interazione (astratto) esponendo i metodi verranno implementati. Essendo interfacce possono realizzare anche ereditarietà multipla (impossibile tra classi). Grazie alla portabilità del codice java (via BYTECODE) si risolve il problema dell’eterogeneità (JVM). Architettura di RMI Per realizzare l’accesso ad un oggetto remoto tramite un riferimento remoto, in RMI (Java) si utilizzano due entità proxy (delegati):
Stub dalla parte del Cliente
Skeleton dalla parte del Servitore
Questi componenti nascondono al livello applicativo la natura distribuita dell’applicazione (pattern Proxy). Non è possibile riferire direttamente l’oggetto remoto -> necessità di una infrastruttura attiva e distribuita. Si definisce prima il contratto e successivamente di definiscono, in modo quasi automatico , le entità proxy. Sono classi già pronte. In questo modo l’utente si occupa solo della parte applicativa. Solo interazioni SINCRONE BLOCCANTI. Client e Server sono scritti dall’utente, Stub e Skeleton sono generati in modo quasi automatico a partire dal contratto definito. Remote Reference Layer e Transport Layer fanno parte della JVM. Il RRL, quando trasferisce variabili per riferimento, trasferisce l’intero grafo. Server SEMPRE Parallelo -> metodi synchronized Il trasporto è SEMPRE connesso (TCP) -> perché si prevede una necessità di banda molto elevata e con semantica at-most-once. rmiregistry sistema di nomi in cui i servitori si devono registrare. I Clienti per ottenere e raggiungere fanno una richiesta al rmiregistry in cui il servitore si è registrato. In tutto 3 entità (JVM): Cliente, Servitore, Registry. Schematizzando: Stub e skeleton (sotto il controllo utente) : o Stub: proxy locale su cui vengono fatte le invocazioni destinate all’oggetto remoto o Skeleton: entità remota che riceve le invocazioni fatte sullo stub e le realizza effettuando le corrispondenti chiamate sul server Il livello Remote Reference Layer (RRL): o Responsabile della gestione dei riferimenti agli oggetti remoti, dei parametri e delle astrazioni di stream-oriented connection Il livello di Trasporto connesso, Transport Layer o Responsabile della gestione delle connessioni fra i diversi spazi di indirizzamento (JVM diverse) o Gestisce il ciclo di vita delle connessioni e le attivazioni integrate in JVM o Può utilizzare protocolli applicativi diversi, purché siano connection oriented -> TCP a livello di trasporto o Utilizza un protocollo proprietario Il sistema di nomi, Registry : servizio di nomi che consente al server di pubblicare un servizio e al client di recuperarne il proxy
Caratteristiche RMI
Il cliente invoca un metodo di un oggetto remoto attraverso un riferimento remoto (variabile interfaccia). Rispetto al locale: Sintassi : uguale -> trasparenza per il cliente. Chiamata sempre sincrona e bloccante con attesa. Semantica: diversa Chiamate locali -> affidabilità massima Chiamate remote: comunicazione con possibilità di fallimento -> semantica “at-most-once” con uso TCP
1
Server remoto come locale: ogni chiamata esegue in modo indipendente e parallelo I componenti remoti sono riferiti tramite variabili interfaccia (che possono contenere solo istanze di classi che implementano la interfaccia) Definizione del comportamento, con o Interfaccia deve estendere java.rmi.Remote (segnala che deve essere visibile da remoto) o Ogni metodo deve propagare java.rmi.RemoteException (eccezioni da remoto) Implementazione comportamento, classe del Server
o o
Deve implementare l’interfaccia definita Deve estendere java.rmi.UnicastRemoteObject
Passi per l’utilizzo di RMI
1. 2. 3.
Definire interfacce e implementazioni (server) dei componenti utilizzabili in remoto Compilare le classi (con javac) e generare, successivamente, stub e skeleton (con rmic) delle classi utilizzabili in remoto Pubblicare il servizio nel sistema di nomi, registry
a. Attivare il registry b. Registrare il servizio (il server deve fare una bind sul registry) 4.
Ottenere (lato client) il riferimento all’oggetto remoto tramite il name service (facendo una lookup sul registry)
A questo punto l’interazione tra il cliente e il server può proced ere
Esempio Echo Intefaccia public interface EchoInterface extends java.rmi.Remote { String getEcho(String echo) throws java.rmi.RemoteException; }
Deve obbligatoriamente estendere Remote. I metodi sono normali con un solo risultato, nessuno, uno o più parametri di ingresso. I parametri devono essere passati per valore (dati primitivi o oggetti Serializable) o per riferimento remoto (oggetti Remote). Server
Client
public class EchoRMIServer extends java.rmi.server.UnicastRemoteObject implements EchoInterface{
public class EchoRMIClient { public static void main(String[] args) { BufferedReader stdIn = new BufferedReader( new InputStreamReader(System.in));
// Costruttore public EchoRMIServer() throws java.rmi.RemoteException { super(); }
try { // Connessione al servizio RMI remoto
// Implementazione del metodo remoto public String getEcho(String echo)
EchoInterface serverRMI = (EchoInterface)java.rmi.Naming.lookup(
throws java.rmi.RemoteException { return echo; }
"//localhost:1099/EchoService");
public static void main(String[] args){ // Registrazione del servizio try {
// Interazione con l'utente String message, echo; System.out.print("Messaggio? "); message = stdIn.readLine(); // Richiesta del servizio remoto echo = serverRMI.getEcho(message); System.out.println("Echo: "+echo+"\n");
EchoRMIServer serverRMI = new EchoRMIServer(); Naming.rebind ( "//localhost:1099/EchoService", serverRMI); } catch (Exception e) {e.printStackTrace(); System.exit(1); } }
} catch (Exception e) { e.printStackTrace(); System.exit(1); } } }
}
Deve implementare tutti i metodi definiti nell’interfaccia. Entità attiva che prepara e registra il servitore sul registry creando una nuova istanza (serverRMI). Invoca tante operazioni di bind/rebind (se esiste lo sovrascrive) quanti sono gli oggetti server da registrare ciascuno con un nome logico. Rimane attivo finchè c’è qualcosa che lo riferisce (anche se finisce il main). In questo caso registry locale (default porta 1099) al server.
Obiettivo del cliente è poter invocare i metodi remoti. Per fare le invocazioni remote si avvale della variabile interfaccia (correttamente “riempita” con il riferimento remoto recuperato
con una lookup nel registry). getEcho() Chiamata sincrona bloccante con i parametri specificati in interfaccia.
2
RMI Registry Localizzazione del servizio: un client in esecuzione su una macchina ha bisogno di
localizzare un server a cui connettersi, che è in esecuzione su un’altra macchina -> Servizio standard (naming service) in una locazione ben nota, che il client conosce, funziona come punto di indirezione. Sistema di nomi realizzato da un utente. Processo che ha l’obiettivo di gestire una tabella costituita da coppie nome del servizio e riferimento dell’oggetto che fornisce il servizio. Lavora con una logica di unicità di nomi. È un Server RMI. RMI è pensato per sistemi piccoli perché i riferimenti, rimanendo attivi, possono riempire rapidamente (e a lungo) la memoria visto che possono essere anche remoti. Classe Naming
Naming: Metodi della classe java.rmi. public static void bind (String name, Remote obj) public static void rebind (String name, Remote obj) public static void unbind(String name) public static String[] list(String name) public static Remote lookup(String name) Ognuno di questi metodi richiede la informazione al RMI registry identificato con host e porta come locazione name -> combina la locazione del registry e il nome logico del servizio, nel formato: //registryHost:port/logical_name registryHost = macchina su cui eseguono il registry e i servitori port = 1099 a default logical_name = il nome del servizio che vogliamo accedere
Attivazione registry (sull’host del server): usare il programma rmiregistry di Sun lanciato in una shell a parte specificando o meno la
porta (default 1099): rmiregistry oppure rmiregistry 10345. N.B.: il registry è attivato così in una nuova istanza separata della JVM. È possibile avviare il registry anche nella stessa JVM del Server. Compilazione ed Esecuzione Lato server
1.
Compilazione interfaccia e implementazione parte server
javac EchoInterface.java EchoRMIServer.java
Hash generato utile alla generazione di Stub e Skeleton. 2.
Generazione eseguibili Stub e Skeleton
rmic [-vcompat] EchoRMIServer Genera:
EchoRMIServer_Stub.class (Client) EchoRMIServer_Skel.class (Server)
Nota : –vcompat in Java 1.5 e seguenti
Prodotti come eseguibili (non modificabili) perché molto legati ai livelli inferiori della JVM. 3.
Esecuzione lato server ( registry e server)
a. Avviamento del registry: rmiregistry b. Avviamento del server: java EchoRMIServer Lato client
1. 2.
Compilazione: javac EchoRMIClient.java Esecuzione: java EchoRMIClient
3
Stub e Skeleton
Rendono possibile la chiamata di un servizio remoto come se fosse locale (agiscono da proxy). Sono generati dalcompilatore RMI. Procedura di comunicazione
1. 2. 3.
Il client ottiene un riferimento remoto con una richiesta (lookup) al registry (default porta 1099) Il client chiama metodi sullo stub e aspetta il risultato (sincrono bloccante) da questo Lo Stub: Effettua la serializzazione delle informazioni per la chiamata (id del metodo – identificazione - e argomenti) Invia le informazioni allo skeleton utilizzando le astrazioni messe a disposizione dal RRL Lo Skeleton : Effettua la de-serializzazione dei dati ricevuti Invoca la chiamata sull’oggetto che implementa il server (dispatching) Effettua la serializzazione del valore di ritorno e invio allo allo stub Lo Stub: Effettua la de-serializzazione del valore di ritorno Restituisce il risultato al client
4.
5.
Passaggio dei parametri Tipo
Metodo Locale
Tipi primitivi Oggetti
Per valore Per riferimento
Metodo Remoto Per valore Per valore (Serializable Object )
-> mandare il contenuto. Deep Copy: viene copiato l’intero grafo
associato alla classe. Oggetti Remoti
Per riferimento remoto (Remote Object)
In Remoto: (problemi nel riferire entità e contenuti non locali)
Passaggio per valore => tipi primitivi e Serializable Object
Oggetti la cui locazione non è rilevante per lo stato sono passati per valore: ne viene serializzata l’istanza che sarà deserializzata a destinazione per crearne una copia locale.
Passaggio per riferimento remoto => Remote Object
Oggetti la cui funzione è strettamente legata alla località in cui eseguono (server) sono passati per riferimento remoto: ne viene serializzato lo stub (riferimento), creato automaticamente a partire dalla classe dello stub. Ogni istanza di stub identifica l’oggetto remoto al quale si riferisce attraverso un identificativo (ObjID) che è univoco rispetto alla JVM dove l’oggetto remoto si trova. Quindi gli oggetti remoti non vengono serializzati ma ne viene serializzato il riferimento -> stub orientato sull’oggetto remoto che contiene quindi solamente il riferimento remoto (leggero). Lo stub contiene un riferimento remoto. Il problema serializzazione dei parametri (sistemi eterogenei), grazie all’uso di BYTECODE, in Java non si presenta visto che i dati vengono semplicemente serializzati/deserializzati utilizzando le funzionalità offerte direttamente a livello di linguaggio => non ci sono operazioni di marshalling e unmarshalling da gestire.
Serializzazione (o Linearizzazione): trasformazione di oggetti complessi in semplici sequenze di byte
Metodo writeObject() su uno stream di output NON viene trasferito l’oggetto vero e proprio ma solo le informazioni contenute che caratterizzano l’istanza. no metodi, no costanti, no variabili static , no variabili transient -> SOLO Dati, no codice. La classe rappresenta la parte descrittiva dell’entità trasferita.
Al momento della deserializzazione sarà ricreata una copia dell’istanza “trasmessa” usando il .class (che deve quindi essere accessibile) dell’oggetto e le informazioni ricevute. Deserializzazione: decodifica di una sequenza di byte e costruzione di una copia dell’oggetto originale Metodo readObject() da uno stream di input Controllo con versioning/ID che consente di verificare la correttezza dei dati ricevuti. L’ID tipicamente è un hash della classe.
Stub e Skeleton utilizzano queste funzionalità per lo scambio dei parametri di ingresso e uscita con l’host remoto.
4
Implementazione del Registry Il Registry è in realtà un server RMI (quindi Parallelo)
Interfaccia: java.rmi.registry.Registry
Classe d’implementazione: sun.rmi.registry.RegistryImpl
public interface Registry extends Remote { public static final int REGISTRY_PORT = 1099; public Remote lookup(String name) throws RemoteException, NotBoundException, AccessException; public void bind (String name, Remote obj) throws RemoteException, AlreadyBoundException, AccessException; public static void rebind (String name, Remote obj) throws RemoteException, AccessException; public static void unbind (String name) throws RemoteException, NotBoundException, AccessException; public static String[] list(String name) throws RemoteException, AccessException; }
È possibile anche creare all’interno del codice (del server) un proprio registry: public static Registry createRegistry (int port) che è un metodo della classe LocateRegistry. In questo caso, il registry viene creato nella stessa istanza della JVM . Implementazione dello Stub Lo stub effettua l’invocazione, gestisce la de/serializzazione, espedisce/riceve gli argomenti e il risultato
Si appoggia sul Remote Reference Layer (RRL) Estende java.rmi.server.RemoteStub Implementa java.rmi.Remote e l’interfaccia remota del server (es. EchoInterface) Contiene al suo interno un’istanza del riferimento all’oggetto remoto (super.ref di classe java.rmi.server.RemoteRef )
// de-serializzazione del valore di ritorno String message1; try{ ObjectInput objectinput =
…
// creazione della chiamata java.rmi.server.RemoteCall remotecall = super.ref.newCall(this, operations, 0, 6658547101130801417L);
remotecall.getInputStream(); message1 = (String)objectinput.readObject();
// 0 indica l’operazione richiesta
}
// serializzazione dei parametri try{ ObjectOutput objectoutput =
…
//segnalazione chiamata andata a buon fine al RRL finally{
remotecall.getOutputStream(); objectoutput.writeObject(message);
super.ref.done(remotecall); //a cosa serve?!?
}
} // restituzione del risultato // al livello applicativo
…
// invocazione della chiamata, sul RRL super.ref.invoke(remotecall);
return message1;
…
…
invoke va alla super-classe, la super-classe fa il codice per
Quando si riceve il risultato si sblocca l’esecuzione del cliente, si
portare il tutto dall’altra parte (ricevuto dallo skeleton)
deserializza l’oggetto ricevuto sullo stream locale e viene
restituito. done: serve perché nella superclasse è stato creato lo stream.
5
Implementazione dello Skeleton
Lo skeleton gestisce la de/serializzazione, spedisce/riceve i dati appoggiandosi sul RRL, ed invoca il metodo richiesto (dispatching). Metodo dispatch invocato dal RRL, con parametri d’ingresso Riferimento al server ( java.rmi.server.Remote) Chiamata remota, numero operazione, e hash dell’interfaccia
public void dispatch(Remote remote, RemoteCall remotecall, int opnum, long hash)throws Exception{
dispatch perché lo skeleton riceve le richieste da vari client -> possono richiedere diversi metodi.
…
EchoRMIServer echormiserver = (EchoRMIServer)remote; switch(opnum){ case 0: // operazione 0 String message; try{ // de-serializzazione parametri ObjectInput objectinput = remotecall.getInputStream(); message =
Ha l’obiettivo di ricevere la richiesta
(unmarshalling dei parametri), portarla verso l’alto e restituire la risposta. Tipicamente funziona in parallelo.
Grosso switch: in base al metodo richiesto esegue l’operazione locale.
(String)objectinput.readObject(); } catch(…){…} finally{ // libera il canale di input remotecall.releaseInputStream(); }
Alla fine invia la risposta ( con marshalling) nello stream in uscita. Non c’è threading. Parallelismo? È nella JVM che implementerà in modo parallelo il servizio che sta eseguendo.
// invocazione metodo String message1 =
echormiserver.getEcho(message); try{ // serializzazione del valore di ritorno ObjectOutput objectoutput = remotecall.getResultStream(true); objectoutput.writeObject(message1); } catch(…){…}
break; … // gestione di eventuali altri metodi
default: throw new UnmarshalException("invalid ..."); } //switch } // dispatch
Livello di trasporto: La concorrenza
Implementazione -> Server parallelo che deve essere thread-safe cioè al livello applicativo dobbiamo comunque tenere in conto problematiche di sincronizzazione => uso di lock: synchronized In RMI si usano i thread di Java => Generazione (poco costosa) di un thread per ogni richiesta che arriva. Non è nello skeleton ma nella JVM. Livello di trasporto: La comunicazione
In Java RMI trasposto connesso => Per motivi di utilizzo di banda maggiore e di qualità. Impegna risorse. All’arrivo di una richiesta RMI si potrebbe: 1. Aprire (ingressi, uscite) e chiudere una sola connessione per ogni richiesta. (Costo elevato) 2. Condivisione di una connessione già aperta. 3. Unica connessione tenuta aperta tra due JVM persistente per un tempo indefinito per servire richieste diverse. (Scelta di RMI) Deployment – Distribuzione della classi
In una applicazione RMI è necessario che siano disponibili gli opportuni file .class nelle località che lo richiedono (per l’esecuzione o per la de/serializzazione) Il Server deve poter accedere a: Interfacce che definiscono il servizio -> a tempo di compilazione
Il Client deve poter accedere a: Interfacce che definiscono il servizio -> a tempo di compilazione
Implementazione del servizio -> a tempo di compilazione
Stub delle classi di implementazione del servizio -> a tempo di esecuzione
stub e skeleton delle classi di implementazione -> a tempo di esecuzione Classi del server usate dal client (es. valori di ritorno) -> a tempo di compilazione o esecuzione Altre classi utilizzate dal client -> a tempo di compilazione o esecuzione
Altre classi utilizzate dal server -> a tempo di compilazione o esecuzione
6
CLASSPATH ed esecuzione Come la variabile d’ambiente PATH di Unix esiste per java la variabile CLASSPATH che dice a RMI dove cercare le cose di cui ha bisogno.
Sotto Linux: ciò è possibile aggiungendo nella propria directory HOME il file ".profile" (creandolo se non esiste). In particolare, il file .profile deve contenere le seguenti linee per aggiungere il direttorio corrente al CLASSPATH: CLASSPATH=.:$CLASSPATH export CLASSPATH (export -> passa la variabile ai processi figli della shell relativa) RMI Class Loading
Tutte le classi e gli oggetti non sono caricati staticamente. Il ClassLoader è quell’entità capace di risolvere i problemi di caricamento dinamico delle classi (a tempo di esecuzione, quando ce n’è bisogno). Le classi possono essere caricate da locale come da remoto (peculiarità di Java). In Java si definisce una gerarchia di ClassLoader , ciascuno responsabile del caricamento di classi diverse, anche definibili dall’utente. I ClassLoader costituiscono ciascuno una località diversa l’uno dall’altro e non interferiscono uno con l’altro: possono avere anche visioni non consistenti. Classloader : risolve i nomi delle classi nelle definizioni delle classi (codice – bytecode). Codebase Classloader (di Java RMI): Responsabili del caricamento di classi raggiungibili con un qualsiasi URL standard (codebase) -> anche da remoto Esempio Applet: Se si usasse lo stesso classloader che si usa per i caricamenti locali (quindi con la stessa “fiducia”) con classi remote ->
problemi evidenti di sicurezza e correttezza. Java ha stabilito che ne possono esistere diversi. Ciascuno riferisce una propria parte di Heap -> più affidabilità -> codice locale e codice remoto gestiti da classloader diversi. Si separa l’ambiente di esecuzione. Per ogni classloader si può definire uno scope di sicurezza. Il Security Manager è un’entità attiva, un controllore di correttezza e sicurezza di ogni singola operazione effettuata durante l’esecuzione. Se le operazioni vanno contro le regole stabilite da un classloader le operazioni vengono fermate (eccezione). Ogni ClassLoader può avere un Security Manager. Sia il client che il server devono essere lanciati specificando il file con le autorizzazioni (file di policy) consultato dal security manager (per il controllo dinamico della sicurezza). RMIClassLoader è un Codebase ClassLoader . Ad esempio, se un cliente non ha lo stub, lo può caricare dal
server tramite codebase. Serve quindi a indicare una specie di repository remoto in cui viene salvato tutto il codice necessario all’esecuzione.
Estrae il campo codebase dal riferimento dell’oggetto remoto
Usa i codebase classloader per caricare le classi necessarie dalla locazione remota
Ogni JVM può specificare il codebase in modo diverso. Nel caso sia necessario ottenere dinamicamente del codice (stub o classi). È necessario: 1. Localizzare il codice (in locale o in remoto) 2. Effettuare il download (se in remoto) 3. Eseguire in modo sicuro il codice scaricato Client e server di una applicazione RMI possono accedere una variabile codebase (annotata nel RemoteRef) in cui è contenuto l’indirizzo remoto (URL) che indica dove è possibile trovare tutto il codice necessario a tempo di esecuzione. L’URL puo’ essere http, ftp
o locale (file://). Per l’esecuzione sicura del codice in RMI si richiede l’utilizzo del RMISecurityManager
RMISecurityManager effettua il controllo degli accessi (specificati nel file di policy) alle risorse di sistema e blocca gli accessi non autorizzati
Il security manager viene creato all’interno dell’applicazione RMI (sia lato client, sia lato server), se non ce n’è già uno istanziato if (System.getSecurityManager() == null) {System.setSecurityManager(new RMISecurityManager()); }
Esempio
Client: java -Djava.security.policy=echo.policy EchoRMIClient Server: java -Djava.security.policy=echo.policy EchoRMIServer
7
Struttura del file di policy: grant { permission java.net.SocketPermission "*:1024-65535", "connect, accept"; permission java.net.SocketPermission "*:80", "connect"; permission java.io.File Permission "c:\\home\\RMIdir\\-", "read";
};
RMI Registry: il problema del bootstrap Come avviene l’avvio del sistema ( bootstrap ) e ritrovare il riferimento remoto?
Java mette a disposizione la classe Naming, che realizza dei metodi statici per effettuare le operazioni di de/registrazione e reperimento del riferimento del server I metodi per agire sul registry hanno bisogno dello stub del registry Come ottenere un’istanza dello stub del registry senza consultare un registry?
Costruzione locale dell’istanza dello stub a partire da: •
Indirizzo server e porta contenuti nel nome dell’oggetto remoto
•
Identificatore (locale alla macchina server) dell’oggetto registry fissato a priori dalla specifica RMI della SUN -> costante fissa
Domanda: è assolutamente necessario un RMIRegistry per una interazione cliente/servitore in RMI? NO perché si può passare il riferimento remoto attraverso i parametri. Problema di sicurezza: accedendo al registry (individuabile interrogando tutte le porte di un host) è possibile ridirigere per scopi maliziosi le chiamate ai server RMI registrati (es. list()+rebind()) Soluzione:
I metodi bind(), rebind() e unbind() sono invocabili solo dall’host su cui è in esecuzione il registry -> non si accettano modifiche della struttura client/server da nodi esterni N.B.: da ciò segue che sull’host in cui vengono effettuate le chiamate al registry deve essercene sempre almeno uno in esecuzione.
8
Università degli Studi di Bologna Facoltà di Ingegneria
Corso di Reti di Calcolatori T Progetto C/S con Socket in C
Antonio Corradi Anno accademico 2012/2013 !"#$%& () * +
COMUNICAZIONE e SOCKET Necessità di Strumenti di Comunicazione per supportare scambio di messaggi Necessità di definire e di diffondere l'uso di strumenti standard di comunicazione Scenario con strumenti diversi, applicativi e di livello diverso Livelli
Interfacce di comunicazione Named Pipe
7
Applicazione
6
Presentazione
Mail Slot
RPC
APPC
Livelli NetBIOS
5
TLI
SPX
Sockets
NetIPC
Specifiche di protocollo Directory
7
Applicazione
6
Presentazione
5
Sessione
Presentazione
4
Trasporto
Sessione
Sessione
4
Trasporto
3
Rete
2
Dati
1
Fisico
X.400 FTAM
TCP / UDP IPX IP
Trasporto
socket come endpoint per comunicare in modo flessibile, differenziato ed efficiente !"#$%& () * ,
UNIX: STRUMENTI di COMUNICAZIONE UNIX ! modello e strumenti per comunicazione/sincronizzazione Si definisce e si regola la comunicazione/sincronizzazione locale Uso di segnali ! processo invia un evento senza indicazione del mittente
Uso di file
!
solo tra processi che condividono il file system sullo stesso nodo
Poi, solo tra processi coresidenti sullo stesso nodo • pipe (solo tra processi con un avo in comune) • pipe con nome (per processi su una stessa macchina) • shared memory (stessa macchina) Comunicazione e sincronizzazione remota ! SOCKET Unix BSD (Berkeley Software Distribution) !"#$%& () * -
UNIX: MODELLO di USO In UNIX ogni sessione aperta sui file viene mantenuta attraverso un file descriptor (fd) privato di ogni processo mantenuto in una tabella di kernel Tabella dei (tabella dei file aperti del processo) descrittori Processo Paradigma di uso: open-read-write-close Processo • apertura della sessione fd 0 fd 1
• • chiusura della sessione
File
pipe
rete Tabella dei file aperti del processo
Socket descriptor dominio servizio
Le socket conformi a questo paradigma con trasparenza rispetto alle azioni sul file system Ovviamente, nella comunicazione si devono specificare più parametri per definire un collegamento con connessione: protocollo di trasporto;
protocollo indirizzo locale porta locale connessione remota
Socket Connessa
e quadrupla
< indirizzo locale; processo locale; indirizzo remoto; processo remoto> !"#$%& () * .
pipe = socket locali in BSD
UNIX: PRIMITIVE UNIX deve fornire funzioni primitive di comunicazione UNIX Berkeley introduce il meccanismo di socket standard, strumenti di comunicazione locali o remote con politiche differenziate, in alternativa ai problemi degli strumenti concentrati, trasparente e ben integrata con processi e file SOCKET su cui i rocessi ossono scrivere/le ere messa i e stream, con molte opzioni e requisiti • eterogeneità: comunicazione fra processi su architetture diverse • trasparenza: la comunicazione fra processi indipendentemente dalla localizzazione fisica • efficienza: l'applicabilità delle socket limitata dalla sola performance • compatibilità: i naive process (filtri) devono potere lavorare in ambienti distribuiti senza subire alcuna modifica • completezza: protocolli di comunicazione diversi e differenziati !"#$%& () * /
UNIX: TRASPARENZA Le socket come strumento con interfaccia omogenea a quella usuale UNIX per i servizi da invocare in modo trasparente • Socket endpoint della comunicazione • Socket descriptor integrato con i file descriptor con protocolli di trasporto diversi e default TCP/IP (sia UDP sia TCP) Chiamata
Significato
open( )
Prepara un dispositivo o un file ad operazioni di input/output
close( )
Termina l'uso di un dispositivo o un file precedentemente aperto Ottiene i dati da un dispositivo di input o da un file, e li mette nella memoria del programma applicativo Trasmette i dati dalla memoria applicativa a un dispositivo di output o un file
read( ) write( ) lseek( )
Muove I/O pointer ad una specifica posizione in file /dispositivo
fctl( )
Controlla le proprietà di un file descriptor e le funzioni di accesso
ioctl( )
Controlla i dispositivi o il software usato per accedervi
Processo utente
Socket system call interface Protocolli di trasporto e di rete (es. TCP/IP)
Kernel
Gestore di data link (es. Ethernet)
!"#$%& () * 0
SOCKET: DOMINIO di COMUNICAZIONE Dominio di comunicazione per socket come specifica del modello: semantica di comunicazione + standard di nomi relativi Esempi di domini: UNIX, Internet, etc. Semantica di comunicazione include - affidabilità di una trasmissione - possibilità di lavorare in mu t cast non solo punto punto Naming modo per indicare i punti terminali di comunicazione Il dominio più appropriato scelto tramite un'interfaccia standard La prima scelta di esempio è tra comunicazione con connessione e senza connessione tipica di ogni dominio DOMINI
descrizione
PF_UNIX
comunicazione locale tramite pipe
PF_INET
comunicazione mediante i protocolli ARPA internet (TCP/IP) ................
...........
!"#$%& () * 1
SCELTE di COMUNICAZIONE Tipi di servizio e socket • datagram: scambio di messaggi senza garanzie (best effort) • stream: scambio bidirezionale di messaggi in ordine, senza errori, non duplicati, nessun confine di messaggio, out-of-band flusso (stream virtuale e non reale) semantica at-most-once • seqpac et: messaggi con numero di ordine (XNS) • raw: messaggi non trattati ma solo scambiati (per debug protocolli)
Protocolli diversi in ogni dominio di comunicazione • UNIX (AF_UNIX) • Internet (AF_INET) • XEROX (AF_NS) • CCITT (AF_CCITT) X.25
!"#$%& () * 2
Ancora SCELTE di COMUNICAZIONE Combinazioni possibili fra dominio e tipo con indicazione del protocollo !"#$ &$'()* +,-./01 +,-0/2! +,-/3 !"#$%& ()*+$" 2%"%3#%& ()*+$" 6%7 ()*+$" !$:;<%*+ ()*+$"
,)((-.-/$ ,)((-.-/$ 8) 8)
01, 42, 519, 8)
!,, 52, ,)((-.-/$ !,,
Protocolli più probabili nello standard Berkeley prefisso AF ! Address Family PF_UNIX, PF_INET, PF_NS, prefisso PF ! Protocol Family cioè address family PF_SNA, PF_DECnet e PF_APPLETALK
=>?58@0 =>?58@0 =>?58@0 =>?58@0 =>?8! =>?8! =>?8! =>?8! =>?485E =>?485E
!"#$%& 2%"%3#%& 6%7 6%7 !"#$%& !$:;<%*+ 6%7 6%7 2%"%3#%& !"#$%&
5,,6A0A?01, 5,,6A0A?42, 5,,6A0A?519, 5,,6A0A?6=B 8!6,6A0A?!,, 8!6,6A0A?!,, 8!6,6A0A?@66A6 8!6,6A0A?6=B 5,,6A0A?42, 5,,6A0A?01,
01, 42, 519, C#%7D !,, !,, @##)# ,#)")*)/ C#%7D 42, 01, !"#$%& () * 3
(Inizio registrazione)
Dominio es Internet
Un end-point viene identificato, in generale da una tripla { Dominio, IP, Porta }
SISTEMA di NOMI per le SOCKET Nomi logici delle socket (nomi LOCALI) ! indirizzo di socket nel dominio Nomi fisici da associare (nomi GLOBALI) ! una porta sul nodo una socket deve essere collegata al sistema fisico e richiede binding, cioè il legame tra socket logica ed entità fisica corrispondente
Half-association come coppia di nomi logica e fisica • dominio Internet: socket collegata a porta locale al nodo { famiglia indirizzo, indirizzo Internet, numero di porta} • dominio UNIX: socket legata al file system locale {famiglia indirizzo, path nel filesystem, file associato} • dominio CCITT: indirizzamento legato al protocollo di rete X.25
In Internet Nodi nomi IP {identificatore_rete, identificatore_host} Porta numeri distintivi sul nodo (1-1023 di sistema, 1024-65535 liberi) !"#$%& () * +4
