motivazioni tradizionali coordinati cooperano...

Reti di Calcolatori: Modelli - 1

RETI DI CALCOLATORI E SISTEMI DISTRIBUITI

UDEFINIZIONE Insieme di sistemi su località diverse che comunicano e cooperano per ottenere risultati coordinati motivazioni tradizionali introducono la possibilità di - accedere a risorse remote - condividere risorse remote come locali SISTEMI di GRANDI DIMENSIONI e MOLTISSIME RISORSE

TRASPARENZA della ALLOCAZIONE QUALITÀ dei SERVIZI (QoS) DINAMICITÀ del SISTEMA

aggiungere risorse al sistema aperto seri problemi teorici (COMPLESSITÀ) Concorrenza: moltissime attività (processi) possono essere in esecuzione Nessun tempo globale: non è possibile una perfetta sincronizzazione degli orologi di un sistema distribuito

Fallimenti indipendenti: molte cause di fallimento, crash di macchine e possibili problemi di rete.

Una macchina isolata dalla rete potrebbe peraltro continuare computazione ...


Sistemi Distribuiti

MOTIVAZIONI tecnologiche ed economiche (Local Area Network LAN - Wide Area Network WAN)

..-

INFOS

COMMS

adeguamento alle richieste distribuite domande distribuite (prenotazioni aeree) eterogeneità degli accessi accessibilità e condivisione delle risorse affidabilità e dependability per potere tollerare guasti uniformità in crescita e scalabilità indipendenza dal numero dei nodi del sistema apertura del sistema capacità di evoluzione secondo necessità


Progetto di una applicazione

Problema

Algoritmo

Linguaggio

di Alto Livello

Architettura

Sistema Operativo

Tecnologiacodifica

mapping

Applicazione

binding

ANALISI e PROGRAMMAZIONE Algoritmo ==> con linguaggio di programmazione (più linguaggi) MAPPING decisioni di allocazione per l'architettura scelta

configurazione a risorse e località BINDING di processi e oggetti decisione di come si agganci ogni entità del

programma alle risorse del sistema GESTIONE STATICA in opposizione a

binding attuato alla esecuzione ==> per una GESTIONE DINAMICA del BINDING e delle RISORSE MASSIMO INTERESSE PER LA PARTE DI SUPPORTO


Reti di workstation Calcolatori indipendenti connessi da una rete locale (LAN)

Tipica architettura MIMD

Multiple Instruction Multiple Data (MIMD) Nodo processore collegato alla memoria privata anche organizzata a livelli

P

M

Rete diInterconnessione

P

M

P

M

P

M

P

M

Nodo P

M

Nodo

Nodo

Nodo

NodoRete diInterconnessione

P

M

P

M

P

M

P

M

Processore

Processore

Cache

Processore

ProcessoreMemoria

LAN

Rete di workstation


Stato dell'arte

esaminando i sistemi operativi dal concentrato verso il distribuito UNIX rappresenta un modello di conformità per caratteristiche di accesso ai file per possibilità di concorrenza per possibilità di comunicazione per le primitive di sistema (kernel) invocabili da diversi linguaggi e ambienti I sistemi operativi general-purpose tendono a fornire soluzioni ispirate o analoghe. Si pensi a:

evoluzioni che fanno ancora i conti con le proprietà di UNIX (vedi anche Linux)

Microsoft Windows NT che introduce processi e controllo di accesso

rinforzato da OPEN SOURCE e FREE SOFTWARE UNIX rappresenta un limite per caratteristiche di concorrenza processi pesanti I sistemi operativi evoluti preservano la compatibilità ottenendo migliori prestazioni nel gestire le risorse per i processi (leggeri) e per la distribuzione delle

risorse (processi e dati)


STATO DELL'ARTE Anziché usare kernel monolitici (vedi UNIX) e che si accettano in blocco (o meno) e che pesano sulle performance Uso di microkernel

realizzazioni minimali del supporto di un S.O. le politiche specificate al disopra del kernel a livello applicativo a livello utente processi applicativi e di sistema

apertura a nuove strategie (generalità) costi superiori delle strategie realizzate (rispetto a soluzione ad-hoc)

I microkernel contengono il supporto per i processi e per le comunicazioni tra processi Le politiche sono realizzate al disopra in spazio utente I microkernel non sono sviluppati solo da ambienti tipo UNIX, ma anche come modello per ambienti tipo Windows in cui l'accento è sulle interfacce grafiche, sulla interazione visuale, etc. In ogni caso, anche gli approcci proprietari devono tenere e tengono in conto di questa evoluzione


Soluzioni STANDARD

APPROCCI AD AMBIENTI APERTI possibilità di avere un ambiente aperto per superare la eterogeneità delle diverse piattaforme anche durante la esecuzione senza fare ripartire il sistema Modelli Object-Oriented Il primo modo richiede un ambiente standard CORBA, ANSA, DCE, OSF, etc. Linguaggio unificante come Java Il secondo modo prevede un ambiente interpretato linguaggi script tipo Shell, TCL/Tk, Perl, Python Java legato allo scenario Web Java si basa su un interprete e una macchina virtuale (JDK1.5)

Applet e Applicazioni Java

Classi Base Estensione di Classi di Java

Java Virtual Machine

Interfaccia di portabilità

Adattatore

Browser

S.O.

Hw

Adattatore

Browser

S.O.

Hw

Adattatore

Browser

S.O.

Hw

Adattatore

Browser

S.O.

Hw

Interconnessione via Rete Java consente una facile integrazione con informazioni Web attraverso applet e la facile integrabilità per distribuzione dinamica del codice sicurezza gestione e monitoraggio delle risorse


DINAMICITÀ

Sistemi di rete

Spesso i sistemi sono solo sistemi di rete in cui le potenzialità non sono sfruttate Scenario Web Informazioni presentate in modo trasparente

utente

abcdef

FORM

INPUT UTENTE

OUTPUT

ELABORAZIONE

elemento

RETE

VISIONE LOCALE

NODI REMOTI

richiesta

rispostaHTTPclient

HTTPserver

TCP / IP TCP / IP

CGI

applicazioni esterneapplicazioni di supporto

rete

sistema remotosistema locale

Se cominciamo a replicare i dati e memorizzare le informazioni su siti intermedi => evoluzione


CLIENTE/SERVITORE

Il modello Client/Server mette in gioco due entità:

l’entità Client richiede il servizio l’entità Server offre il servizio

Nodo C

...richiesta servizio...< attesa risposta >

...ricezione risposta...

ProcessoClient

Nodo S

...< attesa richiesta >ricezione rich. serv....< servizio >

...invio risposta...

Processo Server

Nodo C

...richiesta servizio...< attesa risposta >

...ricezione risposta...

ProcessoClient

Nodo S

...< attesa richiesta >ricezione rich. serv....< servizio >

...invio risposta...

Processo Server

tipico caso di invocazione procedurale:

il cliente aspetta il completamento del servizio attuato dal servitore

il CLIENTE aspetta, il SERVER risponde

MODELLO SINCRONO risposta

BLOCCANTE attesa della risposta il modello Client/Server C/S risolve il problema del rendez vous (per sincronizzare i processi comunicanti) definendo il Server come un processo sempre in attesa di richieste di servizio

Si semplifica in questo modo il protocollo di comunicazione sottostante che non deve occuparsi di attivare un processo alla ricezione di un messaggio


MODELLO CLIENTE/SERVITORE

Modello di comunicazione sincrona e asimmetrica, molti:1

Il Cliente designa esplicitamente il destinatario Il Servitore non esprime il nome del processo con cui desidera comunicare

Nodo A

ProcessoClient 1

Nodo A

ProcessoClient 1

Nodo S

Processo Server

Nodo Z

ProcessoClient N

Nodo Z

ProcessoClient N

il Server deve accedere alle risorse del sistema considerando i problemi di:

autenticazione utenti autorizzazione all’accesso integrità dei dati privacy delle informazioni

e deve gestire richieste contemporanee da molti Client (server concorrenti) Maggiore complessità di progetto dei Server rispetto al progetto dei Client



Mettiamo in gioco due processi Si possono avere anche schemi di interazione diversi

TIME OUT AL CLIENTE

Primo passo verso l’asincronismo e la non attesa Se il cliente ha bisogno di una informazione la richiede => in genere aspetta fino a quando non è disponibile Se il cliente non vuole bloccarsi nella attesa? Timeout: operazioni a tempo, con una durata massima

per il cliente (oltre, non si attende)

TIME OUT E RIPETIZIONI AL CLIENTE

Supponiamo che un cliente sia interessato al risultato di una operazione ma non alla attesa Può usare un ciclo di richieste su sua iniziativa fino ad ottenere la risposta voluta Questo modo carica il cliente della responsabilità dell'ottenere le informazioni CICLO di richieste con timeout ad intervalli scelti dal cliente (polling) una richiesta deve essere

o esaudita subito o restituire un insuccesso e fare partire il lavoro da parte del server

modello pull Reti di Calcolatori: Modelli - 12


MAGGIOR COORDINAMENTO

modello push Si potrebbe risolvere in modo diverso, dividendo le responsabilità il cliente segnala il proprio interesse con una richiesta che viene registrata, poi è libero di fare altro Il server deve:

- registrare la richiesta - eseguire la operazione - inviare la informazione risultato

se e quando disponibile Questa interazione divide i compiti cliente / servitore e forza le informazioni rovesciando i ruoli Il server deve non solo fare le operazioni, ma anche mantenere uno stato delle richieste e della storia della sua esecuzione modello push il servitore diventa cliente del cliente Si possono anche pensare a molte modalità diverse ed eterogeneità di comportamenti

sempre ragionando con interazioni cliente/servitore sincrona di base

Le risposte dal framework al processo utente sono dette backcall o upcall (push del framework)

Un FRAMEWORK costituisce un modello di esecuzione ed un ambiente di richiesta di funzionalità più integrato e tende:

FRAMEWORK


a non replicare la struttura implicita a rovesciare il controllo (per eventi di sistema)

vedi Windows struttura a loop di attesa di eventi che vengono smistati ai richiedenti

meccanismi di supporto della cornice

considerate quindi come eventi asincroni per le applicazioni

Classi esistenti

Funzioni e servizi

matematiche

GUI

ADTs

LOOP

gestioneeventi

di sistema

internet

Database

logica specifica

della applicazione

3D rendering

BACKCALL


MODELLO ad EVENTI

in contrapposizione ad un modello sincrono di richiesta e di attesa della risposta si gestisce la possibilità di inviare messaggi su necessità disaccoppiando gli interessati - I consumatori eseguono le attività - I produttori segnalano le necessità - Il gestore degli eventi segnala l'occorrenza degli

eventi significativi agli interessati

Servizio di Notifica Eventi

produce quotazione

SISTEMA gestoredell'offerta degli eventi

produce quotazione

consuma offerta

consuma offerta

PRODUTTORE

PRODUTTORE

CONSUMATORE

CONSUMATORE

push dell'evento alle entità interessate e registrate Vedi la maggior parte dei sistemi a finestre


MODELLI a DELEGAZIONE

in contrapposizione ad un modello C/S si lascia la possibilità di delegare una funzionalità ad una entità diversa che opera al posto della principale ad esempio, capace di svolgere una funzione per noi entità PROXY, DELEGATE, AGENTI, ATTORI un server lascia una altra entità ad aspettare una risposta ad una operazione. Il proxy lavora in modo push per fornire la risposta al server stesso

Servizio di Delega e Notifica

SISTEMA che svolge

il proxy invia la risposta al richiedente

richiedente

PROXY

la operazione

ad esem

invia richiesta, con delega a un proxy

pio usando eventi locali

A

B

C

La notifica avviene usando eventi come nei framework che si interpongono tra utenti e basso livello e gestiscono il sistema in tutti i suoi dettagli Vedi la maggior parte dei sistemi a finestre


Altri modelli di comunicazione Publish/Subscribe Da una parte una serie di utenti (consumatori) specificano il proprio interesse ad eventi (subscribe) Dall’altra, un gestore registra le loro richieste e notifica gli eventi generati da un produttore ai consumatori sottoscrittori (es. mailing list)

LAN

Servitore di Notifica

PARI (PEER-TO-PEER)

Notifica

Notifica

Notifica

Subscribe

Subscribe

Subscribe

Consum 2

Consum 3

Consum 1

Publish Produttore

le entità in gioco sono tutte pari e possono prendere l’iniziativa secondo necessità e senza ruoli predefiniti (es. Napster)

Due tipi principali di interazione riguardo all’insieme delle richieste



• interazione connection-oriented si stabilisce un canale di comunicazione virtuale prima di iniziare lo scambio dei dati (es. connessione telefonica)

• interazione connectionless

non c’è connessione virtuale, ma semplice scambio di messaggi isolati tra loro (es. il sistema postale)

La scelta tra le due forme dipende dal tipo di applicazione e anche da vincoli imposti dal livello di comunicazione sottostante Per esempio, in Internet il livello di trasporto prevede i protocolli TCP e UDP basati su IP (tipicamente connectionless)

• TCP con connessione, reliable (affidabile) e preserva l’ordine di invio dei messaggi maggiore Qualità del Servizio

• UDP senza connessione, non reliable e non

preserva ordine messaggi


MODELLO DI INTERCONNESSIONE a connessione/ senza connessione CONNESSIONE le entità stabiliscono di preallocare le risorse per la comunicazione (statico)

risorse

dedicatestatiche

SENZA CONNESSIONE le entità comunicano utilizzando le risorse che sono disponibili al momento della azione (dinamico)

dinamicorouting

Alcuni modelli a connessione (TCP basato su IP), non impegnano risorse intermedie

Vedremo questi comportamenti meglio più avanti...


MODELLO di interconnessione concetto di località (limiti alla comunicazione) vs. globalità (nessun vincolo) modelli globali

non impongono restrizioni alle interazioni

entità

comunicazione

operazioni non scalabili dipendenti dal diametro del sistema modelli locali (RISTRETTI) prevedono una limitazione alla interazione

entità

comunicazione

località

operazioni (forse) scalabili poco dipendenti dal diametro del sistema verso la località, i domini, i vincoli per la scalabilità


Due tipi di interazione tra Client e Server

MODELLO DI STATO DEL SERVITORE

stateless, non si tiene traccia dello stato, ogni messaggio è completamente indipendente dagli altri e autocontenuta

stateful, si mantiene lo stato dell’interazione e un messaggio e la operazione conseguente può dipendere da quelli precedenti

Lo stato dell’interazione usualmente memorizzato nel Server (che può essere stateless o stateful)

Un Server stateful garantisce efficienza (dimensioni messaggi più contenute e migliore velocità di risposta del Server) Un Server stateless è più affidabile in presenza di malfunzionamenti (soprattutto causati dalla rete)

Il Server stateful deve potere identificare il Client Per esempio, ci sono notevoli differenze tra un file server stateless e stateful key=open(filename, intentions); rc=read(key, buffer, howmany); stateful rc=write(key, buffer, howmany); stateless rc=read(filename, from, buffer, howmany); rc=write(filename,from, buffer, howmany); (File system NFS di SUN è stateless)


MODELLO STATEFUL /STATELESS

I modelli stateless portano a un progetto del cliente più complesso, ma semplificano il progetto del server I modelli stateful tendono a richiedere al server di mantenere lo stato della interazione

stato del file per ogni file aperto La scelta tra server stateless o stateful deriva anche dalla logica dell'applicazione

Un’interazione stateless è possibile SOLO se il protocollo è progettato per operazioni idempotenti

Ogni richiesta potrebbe non arrivare, o arrivare fuori ordine o ripetuta

Operazioni idempotenti tendono a produrre lo stesso risultato, se ripetute Per esempio, un Server fornisce sempre la stessa risposta a un messaggio M indipendentemente da altri messaggi (anche M) ricevuti dal Server stesso

Ovviamente, a meno che lo stato delle risorse corrispondenti non sia variato

Un server di file system stateless richiede che le operazioni siano controllate dal cliente che mantiene lo stato di ogni file a cui vuole accedere

non si ha necessità della operazione di open sul server


Modello cliente/servitore I modelli base non assumono stato di comunicazione per il servitore 1) NESSUNO STATO nel SERVER (stateless)

2) STATO della interazione sul SERVER

STATO PERMANENTE della interazione ? mantenuto dal cliente o dal servitore STATO SOFT nel SERVER (mantenuto solo per un tempo predeterminato)

- Servitore che tiene traccia dei clienti servitore con stato - Servitore che tiene traccia della storia della

interazione con ogni cliente servitore con stato partizionato: una partizione per ogni sessione di interazione

- Servitore che conosce i clienti uso di una lista per la autorizzazione - Servitore che consente interazione tra i clienti

servitore con stato e interazione mutua tra i clienti attraverso i servizi

- Servitori coordinati con interazione tra i clienti coordinamento dei servitori con stato interazione mutua tra clienti e servitori

Esempi:

Giochi di simulazione distribuita (MOO) Prenotazione aerei Navigazione in Web


CONCORRENZA NEL SERVITORE

Lato Client I Client sono processi sequenziali, con eventuali invocazioni concorrenti supportate dal sistema operativo multitasking Lato Server Il server è un processo ma la concorrenza può essere cruciale per migliorare le prestazioni

Un Server iterativo o sequenziale processa le richieste di servizio una alla volta

Possibile basso utilizzo delle risorse, in quanto non c’è sovrapposizione tra elaborazione ed I/O

Un Server concorrente può gestire molte richieste di servizio insieme (concorrentemente), cioè il server può accettare una richiesta anche prima del termine di quella (o quelle) attualmente in corso di servizio

Migliori prestazioni ottenute da sovrapposizione elaborazione ed I/O Maggiore complessità progettuale

non necessariamente progetto con processi multipli (e attività parallele)

Si pensi ad un Web server che deve rispondere a moltissime richieste contemporaneamente


POSSIBILI SERVITORI

schema di massima

Tipo di comunicazione

iterativo

con connessione senza connessione

concorrentemultiprocesso

singoloprocesso

Tipo di Server

La scelta del tipo di Server dipende

dalle caratteristiche del servizio da fornire


iterativo


concorrentemultiprocesso

singoloprocesso

Tipo di Server


iterativo


concorrente

multiprocesso

singoloprocesso

La scelta del tipo di Server dipende

dalle caratteristiche del servizio da fornire

SERVER

concorrente

sequenziale

Vari tipi di Server dipende dal tipo di protocollo e dalla tecnologia realizzativa della esecuzione e della comunicazione tra cliente e servitore

servizio sequenziale vs concorrente servizio con vs senza connessione servizio con vs senza stato

Per esempio, in Unix è facile realizzare un Server concorrente generando un processo nuovo (fork) per ogni richiesta di servizio (server concorrente multi processo)


Modelli di SERVIZIO

servizio sequenziale o iterativo

il servitore considera le richieste una alla volta ritardi nel servizio stesso ai clienti

servizio concorrente il servitore serve più richieste insieme maggiore complessità progettuale del server NON necessario il parallelismo nel server

servizio senza connessione

(ad esempio usando UDP) costo basso, ma si devono realizzare ordinamenti e reliability

servizio con connessione (ad esempio usando TCP) costo superiore della realizzazione

servizio senza stato (stateless server)

il servitore considera le richieste e le dimentica appena fornite

problemi nella gestione di richieste replicate senza rieseguire il servizio

servizio con stato (stateful server) il servitore tiene traccia dello stato di interazione dei servizi con i clienti

maggiore complessità progettuale del server NON facile decidere lo stato in concorrenza


Server Sequenziale Distinguiamo dal punto di vista cliente - tempo di elaborazione (di servizio) di una richiesta

TS tempo per servizio di una richiesta isolata - tempo di risposta osservato dal cliente TR

TR = TS + 2 TC + TQ TC tempo di comunicazione medio TQ tempo di accodamento medio

TR ritardo totale tra la spedizione della richiesta e l'arrivo della risposta dal server

Con lunghe code di richieste, il tempo di risposta può diventare anche molto maggiore del tempo di elaborazione della richiesta

Server sequenziale una richiesta alla volta e accoda le altre richieste Tralasciando il tempo di comunicazione, se N è la lunghezza della coda ==> TR (medio) = (N/2+1) * TS Soluzione: limitare la lunghezza della coda e rifiutare le richieste a coda piena

CODA DELLE

RICHIESTE

Operazione

Processo

SERVER

Richieste dai clienti

Risposta al cliente


Server Concorrenti Concorrenza può migliorare il tempo di risposta: se la risposta richiede un tempo di attesa

significativo di I/O o di sospensione del servizio con possibilità di interleaving

se le richieste richiedono tempi di elaborazione molto variabili

se il server è eseguito in un multiprocessore, cioé con servizi in reale parallelismo

TR = TS + 2 TC + TQ + TI + TG; TC tempo di comunicazione medio TQ tempo di accodamento medio (trascurabile)

TI tempo di interleaving con altri servizi concorrenti TG tempo di generazione di un eventuale servitore

Sono possibili schemi diversi di realizzazione di un server di questo tipo

CODA DELLE

RICHIESTE

Processo

SERVER


Risposta al cliente Processo

FIGLIO

Processo

FIGLIO

Processo

FIGLIO

servitore concorrente

CODA DELLE

RICHIESTE

Processo

SERVER


Risposte al cliente Operazioni

CLiente1

Operazione

Cliente2

Operazione

ClienteN

servitore concorrente multiprocesso singolo processo


PROCESSI

Processi differenziati

Processo pesante

Dati

Stack /Heap

Codice

Processi leggeri

Dati

Stack

Codice

Thread 1Thread 2Thread 3

Thread 1

Thread 2

Thread 3

modello dei processi processi pesanti / processi leggeri IMPLEMENTATIVAMENTE Processo SPAZIO di indirizzamento SPAZIO di esecuzione insieme di codice, dati (statici e dinamici),

parte di supporto, cioè di interazione con il sistema operativo (file system, shell, socket, etc.) e per la comunicazione

un'aggregazione di parecchi componenti Processo pesante ad esempio in UNIX cambiamento di contesto operazione molto pesante overhead

ad esempio in UNIX, i thread o

Processi leggeri

SOLUZIONE al PROBLEMA


creare entità più leggere con limiti precisi di visibilità e barriere di condivisione

attività che condividono visibilità tra di loro e che sono caratterizzata da uno stato limitato overhead limitato

lightweight process Quale contenitore unico si può considerare per la visibilità dei thread? In genere, un processo pesante che contiene più processi leggeri Tutti i sistemi vanno nel senso di offrire granularità differenziate per ottenere un servizio migliore e più adatto ai requisiti dell'utente Si useranno processi pesanti quando è il caso e processi leggeri se si vuole avere un overhead più limitato

Il processo pesante funziona anche da contenitore di processi leggeri

In caso di mobilità, si deve considerare cosa muovere e se siamo facilitati nel farlo


modello di esecuzione Entità ed interazione modello a processi Processo

entità in esecuzione che possono eseguire e comunicare direttamente o indirettamente con altri processi attraverso - memoria condivisa - scambio di messaggi

Uso di dati esterni ai processi stessi (scarso confinamento) modello ad oggetti (e processi) Oggetto

entità dotata di astrazione che racchiude risorse interne (astrazione) su

cui definisce operazioni agisce su risorse interne alla richiesta di

operazioni dall'esterno

- oggetti passivi astrazioni su cui agiscono processi esterni - oggetti attivi capaci di esecuzione e scheduling


OGGETTI E PARALLELISMO

come inserire il parallelismo in un modello ad oggetti a) affiancando il concetto di PROCESSO a quello di OGGETTO

STATO

OGGETTO PROCESSO

===> modelli ad oggetti PASSIVI SVANTAGGI: perdita di uniformità e di protezione Java

STATO STATO

b) integrando PROCESSO ed OGGETTO ===> modelli ad oggetti ATTIVI VANTAGGI: uniformità di concetti protezione information hiding

STATO STATO

Modello a maggior confinamento Non esistono processi che si muovono sugli oggetti Oggetti Attivi decidono independentemente e nascondono il comportamento interno


Oggetti attivi Ogni oggetto racchiude al proprio interno la necessaria capacità di concorrenza e definisce la propria gestione della concorrenza Ogni oggetto deve prevenire eventuali interferenze

CODA DELLE

ATTIVITA'

CODA DELLE

RICHIESTE

SCHEDULER

RICHIESTE DA

ALTRI OGGETTI

Parte Parallela

Parte non Parallela

v0

v1

v2

v3

ATTIVITA'

m3m2m1m0

METODI

STATO

m4

Stato di Scheduling

Oggetto

GESTORE

Separazione della dimensione interoggetto dimensione intraoggetto È più facile considerare un processo od un oggetto? e i suoi riferimenti verso altri oggetti (come cliente) e i riferimenti verso l'oggetto stesso (come servitore) Struttura simile a quella di un servitore come quelli che vogliamo realizzare


PROGETTO DI CLIENTI E SERVITORI

Il progetto dei clienti è più semplice del progetto dei servitori che sono intrinsecamente più complessi Non solo il progetto di un server è tipicamente più complesso per la operazione svolta dal server stesso e dai clienti solo richiesta (molti a 1) Ma anche…

Un server deve essere sempre presente al momento delle richieste dei clienti Il server deve essere sempre presente

come lo si può garantire? I server sono tipici processi demoni sulle macchine server e sopravvivono alla durata delle singole applicazioni per vivere per tutta la durata del sistema

Daemon tipici processi server che eseguono un ciclo infinito di attesa di richieste ed esecuzione delle stesse

Java riconosce l’importanza dei thread daemon e riconosce thread user e thread daemon

la JVM termina l’esecuzione dei daemon thread solo quando termina l’ultimo user thread I daemon thread svolgono servizi per gli user thread e spesso restano in esecuzione per tutta la durata di una sessione della virtual machine (vedi garbage collector)


PROGETTO DI CLIENTI E SERVITORI

come si distribuisce la logica applicativa tra i Client e i Server? In genere il server prevede un progetto complesso e il client deve essere più snello Fat Client vs. Thin Client Considerazioni di configurazione del sistema, di carico sul server, di traffico di rete

Application logic Application logic

Database logicDatabase logic

Presentation logic (GUI)Presentation logic (GUI)

Client Server

DatabaselogicDatabaselogic



Client ServerFat Client

Thin Client


SISTEMI MULTI TIER

Un sistema C/S può essere anche decomposto in parti (3-tier C/S), per distribuire il carico di lavoro di un Server su diverse macchine Si possono anche avere molti nodi diversi che si incaricano di svolgere funzioni molto diverse e sono separate nel sistema per ragioni diverse di bilanciamento di carico di limiti di esecuzione di disponibilità e tolleranza ai guasti di vicinanza geografica


Client


Server

Database logicDatabase logic

Server

SQLSocket, RPC, HTTP


modello di comunicazione schema di base C/S sincrono e bloccante I servizi sono forniti da un servitore che risponde a diversi clienti (molti:1) - i clienti conoscono il servitore - il servitore rappresenta la astrazione dei servizi e non conosce i possibili clienti MODELLO astratto asimmetrico interazione sincrona (default) anche asincrona / non bloccante

asincrona nessun (interesse per) risultato non bloccante non interessa aspettare risultato

schemi più complessi clienti / servitori multipli I servizi sono forniti da più servitori (molti:molti) con diverse possibilità - 1 solo servizio per ogni richiesta (stampa di un file) - 1 servizio da ogni possibile servitore (aggiorna copie di un file) Necessità di coordinamento tra i servitori con Replicazione o Suddivisione

importanza di stabilire il numero di operazioni che si vogliono ottenere ?1 sola stampa ?aggiornamento di tutte le copie

(e attesa del completamento di tutte le operazioni) (o attesa parziale)


Schema agenti multipli / clienti

I servizi sono forniti dal coordinamento di più servitori detti agenti che forniscono un servizio globale unico modello two tier gli agenti forniscono il servizio coordinato e possono: - partizionare le capacità di servizio - replicare le funzionalità di servizio in modo trasparente al cliente

CLIENTE AGENTI

entità

richiesta di servizio

cliente

servizio coordinato agenti

Mail

UA MTA MTA

MTA

sistema B

sistema A sistema C

Posta

UA


schemi a clienti/agenti/servitori multipli

CLIENTE AGENTI / SERVITORI e RISORSE

agenticlienti servitori

risorse

AGENTI

anche paralleli e capaci di coordinarsi SERVITORI

anche paralleli replicati e coordinati PROTOCOLLI

di coordinamento, sincronizzazione, rilevazione e tolleranza ai guasti

Due livelli di coordinamento nell'accesso alle risorse da parte dei clienti modello three tier MODELLI a LIVELLI MULTIPLI per la divisione dei compiti

confinando il lavoro sul livello meno congestionato schemi di comunicazione a multicast/broadcast


modelli preventivi / reattivi modelli ottimisti e pessimisti Esempi approcci per gestire il deadlock - approcci che prevengono il deadlock

avoidance si evita a priori tramite introduzione di forti vincoli (sequenzializzazione completa)

prevention si evita la specifica situazione con algoritmi (accesso in ordine)

- approcci che fanno fronte all'occorrenza del

deadlock recovery se succede, interveniamo il problema della interferenza/congestione - ring previene la congestione con regole precise di

controllo di accesso - CSMA/CD tenta l'accesso senza controllo e deve

tenere conto della interferenza possibile, con opportune strategie

I primi sono approcci pessimisti/preventivi I secondi sono approcci ottimisti/reattivi Naturalmente, in genere i sistemi preventivi sono statici per l'aspetto

considerato i sistemi reattivi sono dinamici


modello di nomi e sistemi di nomi conoscenza reciproche delle entità / servizi

in una relazione cliente/servitore il cliente deve avere un riferimento al servitore indirizzoServizio nomeNodo.nomeServizio nomeGestore.nomeServitore nomeServitore nomeServizio NON TRASPARENZA vs. TRASPARENZA dei servizi ai nodi degli indirizzi all'interno del nodo Notiamo che i riferimenti sono distribuiti nel codice dei clienti, degli utilizzatori, delle librerie, ecc. Si deve garantire la consistenza Come e si qualificano i nomi e quando si risolvono i riferimenti?

BINDING STATICO VS. DINAMICO statico: i riferimenti sono risolti prima della esecuzione dinamico: i riferimenti sono risolti al bisogno In caso di sistemi concentrati =>

Binding tipicamente statico ma a causa delle necessità di riutilizzo

anche librerie dinamiche


NOMI nel DISTRIBUITO

CASO STATICO invarianza dei nomi e della allocazione delle entità

si risolve il tutto staticamente e non si necessita di un servizio di nomi

I nomi sono risolti prima della esecuzione e non è il caso di cambiare alcuna allocazione (altrimenti insorgono problemi) CASO DINAMICO In caso dinamico, nasce la necessità di un servizio di nome (name server) che mantiene e risolve i nomi e fornisce il servizio durante la esecuzione coordinandosi con i gestori della allocazione CASO DINAMICO entità non staticamente fissate

Uso di tabelle di allocazione ==> controllate da opportuni GESTORI dei NOMI

nomi non trasparenti dipendenti dalla locazione nomi trasparenti non dipendenti dalla locazione DINAMICITÀ E se le entità si muovono? si devono riqualificare i nomi per ogni possibile cliente entità trasparenti e NOMI invarianti INDIPENDENZA dalla ALLOCAZIONE


MODELLO DI NOMI IN SISTEMI APERTI possibilità di inserire nuove entità compatibili con il sistema già esistente

COORDINAMENTO di gestori di nomi distinti partizionamento dei gestori

ciascuno responsabile di una sola partizione dei riferimenti - località (in generale i riferimenti più richiesti)

replicazione dei gestori ciascuno responsabile con altri di partizione dei riferimenti - coordinamento

Spesso organizzazioni a livelli gestore generale che coordina gestori di più basso livello in molti livelli con località informazioni (vedi DNS)

reston

cc

us

cc cs ecn

purduedec

com edu

xinu

gov

nfs

dipmatdeis

unibo

it

cineca


DOMAIN NAME SYSTEM (DNS) Insieme di gestori di tabella di nomi logici e di indirizzi IP obiettivo principale => attuare corrispondenze tra nomi di host e indirizzi IP Primo passo: uso di un file locale, /etc/hosts Non sufficiente su scala globale (quante repliche?) NOMI LOGICI GERARCHICI Gerarchia di domini logici e centri di servizio

reston

cc

us

cc cs ecn

purduedec

com edu

xinu

Radice innominata

gov

nfs

cs

unibo

it

cineca

deis33

deis

deis33

Anche alias

la corrispondenza tra nomi logici e indirizzi fisici avviene dinamicamente tramite un servizio di nomi che risponde (dinamicamente) alle richieste di traslazione La traslazione: statica vs. dinamica locale vs. globale non una gestione globale centralizzata o statica Esempio di divisione dei compiti e coordinamento replicazione partizionamento


NOMI DI DNS GERARCHICI

Ogni nome rappresenta un dominio e può identificare sia un host sia un ulteriore insieme di nodi

Nome dominio Significato COM Organizzazioni commerciali

EDU Istituzioni per l'istruzionre

GOV Istituzioni governative

MIL Gruppi militari

NET Maggiori centri di supporto alla rete

ORG Organizzazioni diverse dalle precedenti

ARPA Dominio temporaneo dell'ARPANET (obsoleto)

INT Organizzazioni internazionali (schema geografico)

codice nazionale Ciascuna nazione (schema geografico)

deis33.cineca.it a tre livelli NOME con vari identificatori (o label ) ciascuna un dominio

Livello Descrizione Nome dominio Sigle minimo locale deis33.cineca.it deis33 = macchina

intermedio gruppo cineca.it cineca = gruppo massimo organizzazione it it = Italia

deis33.deis.unibo.it country it = Italia, organisation unibo = Università di Bologna, dept deis = Nome/Sigla Organizzazione locale, machine deis33 = nome della macchina,

Livello Descrizione Nome dominio Sigle minimo locale deis33.deis.unibo.it deis33 = Host

intermedio2 sottogruppo deis.unibo.it deis = Organisation intermedio1 gruppo unibo.it unibo = U of Bologna

massimo postazione it it = Italy


int

Nomi di DNS

I singoli nomi sono case insensitive e al max 63 char Il nome completo al max 255 char I domini non sono collegati in nessun modo alle reti fisiche o alle organizzazioni (logico vs. fisico) Ogni dominio indicato in modo relativo o assoluto Ogni dominio deve fare riferimento al dominio che lo contiene deis.unibo.it deis è interno a unibo, interno a it, che è interno alla root Possibile gerarchia

com edu gov mil org net it uk fr

yalesun acm ieee cineca unibo inria

java cs eng jack jill deis cs eng

CountriesGeneric

unims

Il tutto è organizzato a ZONE, ogni zona riconosce una autorità ossia un servizio che fornisce le corrette corrispondenze suddivisione in zone geografica o di organizzazione

int com edu gov mil org net it uk fr

yale sun acm ieee cineca unibo inria

java cs eng jack jill deis cs eng

Generic Countries

unims


Implementazione DNS

CONCETTO DI DELEGA

I Domini sono divisi in zone d’autorità soggette a diversi servitori che possono a loro volta delegare la gestione

un Dominio delega i sottodomini a servitori sottostanti (che se ne assumono responsabilità e autorità)

Diversi requisiti => affidabilità, efficienza, località Ogni richiesta viene fatta al servizio di nomi tramite un agente specifico (name revolver) di gestione dei nomi per una località

Ogni dominio ha uno o più name resolver

API per chiedere ad un revolver di mappare un riferimento Il resolver fornisce la risposta perché: • conosce già la corrispondenza (cache) o • la trova attraverso una richiesta C/S a un name server

I DNS name server sono organizzati come agenti per ottenere informazioni reciprocamente (dalla più corretta autorità)

Affidabilità


Diversi DNS come domini separati Ogni dominio corrisponde al Name Server che ha autorità sulla traslazione degli indirizzi che non ha una visione completa, ma solo locale In genere, ogni zona ha un primary master responsabile per i dati della intera zona ma in più ci sono una serie di secondary master che sono copie del primary, con consistenza garantita dal protocollo DNS (non massima)

allo start up il secondario chiede i dati al primario e può fare fronte al traffico in caso di guasto Ad intervalli prefissati, i secondari chiedono le informazioni al primario (modello pull)

È bene avere più server master per zona I ruoli sono mescolati in modo libero: primario di una zona può diventare il backup (master secondario) di un'altra zona Efficienza su località

i dati ottenuti possono essere richiesti nuovamente i server mantengono informazioni caching dei diversi server per ottimizzare i tempi di risposta al cliente

Protocollo di richiesta e risposta per il name server con uso di protocollo UDP (comunicazione porte 53) e se messaggi troppo lunghi? Eccezione e uso di TCP


DNS - implementazione

DNS Risoluzione nomi Alcune scelte dipendenti dalla implementazione

il resolver conosce un server di dominio e attua le query

Il protocollo DNS regola gli scambi di informazioni tra server: due tipi di query ricorsiva e iterativa La ricorsiva richiede che al cliente o si fornisca risposta (anche chiedendo ad altri) o si segnali errore (dominio non esistente, etc.) La iterativa richiede che al cliente si fornisca o la risposta o il migliore suggerimento come un riferimento al migliore name server

Il resolver query tipicamente ricorsiva il server di dominio si incarica di rispondere coordinandosi con altri (query iterativa)

resolver

pippo.cineca.ittrova

Server

Dominio

Secondari

client

Gestoredeis.unibo.it

unibo.itRIF a it

it

cineca.it

RIF a cineca.it

trovato per pippo.cineca.it137.205.88.00

Server

Dominio

Secondari

pippo.cineca.itServer di

Dominio

ALBERO

(1)(2)

(3)

(4)


Risoluzione dei nomi

Il servizio distribuito e a dati partizionati ottenuto scambiando query tra DNS server Se il server possiede il nome, risponde

Se query ricorsiva, cerca altre risposte e rimane impegnato fino a risposta o time-out Se query iterativa, il server che non possiede il nome risponde con un riferimento al gestore superiore più vicino che possa rispondere (si continua a scalare la gerarchia in modo dinamico, senza conoscerla a priori)

Il name server locale fa query iterativa, senza conoscere a priori la gerarchia (località) Ogni name server decide se e come rispondere Il name server root non accetta query ricorsive anche altri che devono fornire sempre servizi Si usano timeout ed eventualmente il server ne consulta successivamente altri e se le zone hanno secondari, ci si rivolge a quelli Tipicamente, si provano diversi server noti mandando a ciascuno almeno due o più ritrasmissioni con time-out crescenti (4 volte) se non c'è risposta si assume che il server sia fallito (timeout = server crash)


Valore

DNS - informazioni

Un server mantiene un record per ogni risorsa dinamico (caricato da file di configurazione ed aggiornato)

Le query consultano l'insieme dei record Nome dominio Time to live (tempo validità in secondi) Classe (Internet IN) Tipo (descrizione del tipo) Valore

I tipi significativi Tipo Significato

SOA Start of Authority parametri della zona

A IP host address intero a 32 bit (dot not.)

MX Mail exchange server di domino di mail

NS Name server server per dominio corrente

CNAME Canonical name alias di nome in un dominio

PTR Pointer per corrispondenza inversa

HINFO Host description descrizione di host e SO

TXT Text testo qualunque

Sono possibili anche accessi e query inverse: ossia PTR si entra con l'indirizzo e si ottiene il nome

Il tutto richiede (?) record per corrispondenza inversa...

1 2

137 255

in-addr arpa

ipotetica radice

3

2551 204

2551 57

2551 33


Esempio di record DNS @ IN SOA promet1.deis.unibo.it. postmaster.deis.unibo.it. (644 10800 1800 604800 86400) ; serial number, refresh, retry, expiration, TTL in sec ; versione , 3 ore , 1/2 o, 1 sett. , 1 d IN NS promet1.deis.unibo.it. IN NS promet4.deis.unibo.it. IN NS almadns.unibo.it. IN NS admii.arl.army.mil.

localhost IN A 127.0.0.1 @ A 137.204.59.1 MX 10 deis.unibo.it. MX 40 mail.ing.unibo.it.

lab2 IN NS lab2fw.deis.unibo.it. lab2fw IN A 137.204.56.136 amce11 IN A 137.204.57.244 IN HINFO HW:PC IBM SW:WINDOWS 95 IN WKS 137.204.57.244 TCP FTP TELNET SMTP IN MX 40 amce11.deis.unibo.it. labvisione IN CNAME csite27 deis18 IN TXT "Qualunque testo non significativo" deis18 IN RP root.deis.unibo.it luca\.ghedini.mail.ing.unibo.it ; record per responsabile

@ IN SOA promet1.deis.unibo.it. postmaster.deis.unibo.it. (644 10800 1800 604800 86400) IN NS promet1.deis.unibo.it. IN NS promet4.deis.unibo.it. IN NS almadns.unibo.it. IN NS admii.arl.army.mil. 146 IN PTR deiscorradi.deis.unibo.it. ; record per la corrispondenza inversa

usare nslookup per la analisi


> unibo.it.

Server: promet1.deis.unibo.it Address: 137.204.59.1 res_mkquery(0, unibo.it, 1, 1) Got answer: HEADER: opcode = QUERY, id = 15, rcode = NOERROR header flags: response, want recursion, recursion avail. questions =1, answers =1, authority records = 4, additional =4 QUESTIONS: unibo.it, type = A, class = IN ANSWERS: -> unibo.it internet address = 137.204.1.15 ttl = 58196 (16 hours 9 mins 56 secs) AUTHORITY RECORDS: -> unibo.it nameserver = dns2.cineca.it ttl = 155488 (1 day 19 hours 11 mins 28 secs) -> unibo.it nameserver = dns.nis.garr.it ttl = 155488 (1 day 19 hours 11 mins 28 secs) -> unibo.it nameserver = dns.cineca.it ttl = 155488 (1 day 19 hours 11 mins 28 secs) -> unibo.it nameserver = almadns.unibo.it ttl = 155488 (1 day 19 hours 11 mins 28 secs) ADDITIONAL RECORDS: -> dns2.cineca.it internet address = 130.186.1.1 ttl = 258410 (2 days 23 hours 46 mins 50 secs) -> dns.nis.garr.it internet address = 193.205.245.8 ttl = 119860 (1 day 9 hours 17 mins 40 secs) -> dns.cineca.it internet address = 130.186.1.53 ttl = 258410 (2 days 23 hours 46 mins 50 secs) -> almadns.unibo.it internet address = 137.204.1.15 ttl = 414688 (4 days 19 hours 11 mins 28 secs) ------------ Non-authoritative answer: Name: unibo.it Address: 137.204.1.15


> cineca.it. Server: promet1.deis.unibo.it res_mkquery(0, cineca.it, 1, 1) ------------ Got answer: HEADER: opcode = QUERY, id = 28, rcode = NOERROR header flags: response, want recursion, recursion avail. questions =1, answers =0, authority records =1, additional = 0 QUESTIONS: cineca.it, type = A, class = IN AUTHORITY RECORDS: -> cineca.it ttl = 10784 (2 hours 59 mins 44 secs) origin = dns.cineca.it mail addr = hostmaster.cineca.it serial = 1999052501 refresh = 86400 (1 day) retry = 7200 (2 hours) expire = 2592000 (30 days) minimum ttl = 259200 (3 days) ------------ Name: cineca.it ; query inverse > set q=ptr > 86.57.204.137.in-addr.arpa. Server: promet1.deis.unibo.it Address: 137.204.59.1 86.57.204.137.in-addr.arpa name = deis86.deis.unibo.it 57.204.137.in-addr.arpa nameserver = admii.arl.army.mil 57.204.137.in-addr.arpa nameserver = almadns.unibo.it 57.204.137.in-addr.arpa nameserver = promet4.deis.unibo.it 57.204.137.in-addr.arpa nameserver = promet1.deis.unibo.it admii.arl.army.mil internet address = 128.63.31.4 admii.arl.army.mil internet address = 128.63.5.4 almadns.unibo.it internet address = 137.204.1.15


BIND (Berkeley Internet Name Domain) Implementazione di Berkeley di DNS La prima significativa come ampiezza e poi diffusione comando nslookup come ambiente di interrogazione per le corrispondenze e le inverse comando nstest come shell di interrogazione I resolver sono invocati anche all'interno di applicazioni rlogin, telnet ... Molti particolari implementativi In genere, i server sono paralleli si usano cache di risultati negativi

SERVER SPECIALIZZATI

I server primari e secondari appartengono a domini diversi la non località può portare a operazioni di aggiornamento costose partial-secondary server

gestori secondari partizionati che mantengono un sottodominio ed una località

caching-only server puri gestori di record che sono solo capaci di mantenere entry cached e rispondere a query inverse

forwarder server interni a una località che accettano query ricorsive per fornire sempre risposta

Si cominciano a considerare caratteristiche di sicurezza • limitando i clienti che possono accedere (e le operazioni

che possono richiedere) • limitando le zone che altri name server possono chiedere


STANDARD di comunicazione ISO - OSI

OSI Open System Interconnection Obiettivi di INTERCOMUNICAZIONE tenendo conto di reti e sottoreti e di tecnologie diverse proprietarie

Application

Presentation

Session

Transport

Network

Link

Physical

Network

Link

Physical

Network

Link

Physical

Application

Presentation

Session

Transport

Network

Link

Physical

Node Node

Sub-net

End to end peer protocols

Sub-net access protocols

Communications Subnet Boundary

Host A Host B

ESEMPI di sistemi APERTI UNIX che non lega ad un produttore, con software free (open source)

Vantaggi degli standard INTEROPERABILITÀ anche TCP/IP ossia Internet per la interconnessione di Reti distinte

Anche Internet prevede e mappa alcuni livelli come OSI

Trasporto

Rete

Data Link1

2

3

4 Processo

Si considerano i livelli di rete e trasporto e i rispettivi sistemi di nomi NOMI di newtork IP NOMI di trasporto PORTE


classe A

INDIRIZZAMENTO GERARCHICO IP Ogni connessione a una rete indirizzo Internet unico a 32 bit IP-ADDRESS NETID, HOSTID un identificatore di rete NETID e di host HOSTID gli indirizzi sono contestuali locali Legame con la rete e routing IP individua connessioni nella rete virtuale ==> astrazione dell'indirizzo hardware fisico (nomi livello 2) indipendente da questo (non in dipendenza dalla locazione di accesso) STANDARD IETF nomi dati di autorità

Network Information Center (NIC) assegna il numero di rete, cioè l'informazione usata nei gateway per routing

CLASSI di indirizzi

classe B

classe C

classe D

classe E

0

1

1 1

1 1 1

1 1 1 1

0

0

0

0

0 1 2 3 4 8 16 24 31

netid hostid

hostid

hostid

netid

netid

indirizzo multicast

indirizzi riservati ad usi futuri Classi degli IP address

motivazioni tradizionali coordinati cooperano...

Documents

Transcript of motivazioni tradizionali coordinati cooperano...