Sistemi di Nomi e RPC- 1
modello di naming e sistemi di nome conoscenza reciproca 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
Sistemi di Nomi e RPC- 2
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 problemi) E se le entità si muovono? entità trasparenti e NOMI invarianti INDIPENDENZA dalla ALLOCAZIONE nomi non trasparenti dipendenti dalla locazione corrente solo TRASPARENZA dalla ALLOCAZIONE si devono riqualificare i nomi di tutti i possibili clienti 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
Sistemi di Nomi e RPC- 3
modello di naming 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 CORBA o DNS)
reston
cc
us
cc cs ecn
purduedec
com edu
xinu
gov
nfs
dipmatdeis
unibo
it
cineca
Sistemi di Nomi e RPC- 4
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: /etc/hosts Non sufficiente NOMI LOGICI GERARCHICI Gerarchia di domini logici
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
Sistemi di Nomi e RPC- 5
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
Sistemi di Nomi e RPC- 6
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
Il tutto è organizzato a ZONE, ogni zona riconosce una autorità che fornisce le corrette corrispondenze suddivisione in zone geografica o di organizzazione
int com edu gov mil org net it uk fr
yalesun acm ieee cineca unibo inria
java cs eng jack jill deis cs eng
Generic Countries
unims
Sistemi di Nomi e RPC- 7
Implementazione DNS CONCETTO DI DELEGA un Dominio delega i sottodomini a gestori sottostanti (che se ne assumono responsabilità e autorità) I Domini sono divisi in zone di autorità soggette a diversi servitori che possono delegare anche altri della gestione Diversi requisiti => affidabilità, efficienza, località Ogni richiesta viene fatta al servizio di nomi tramite un agente specifico di gestione dei nomi per una località
a livello di API si passa il riferimento da mappare ad un resolver che • conosce già la corrispondenza (cache) • 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à)
Sistemi di Nomi e RPC- 8
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)
Affidabilità
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
Sistemi di Nomi e RPC- 9
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)
client
resolver
pippo.cineca.ittrova
Gestoredeis.unibo.it
unibo.itRIF a it
it
cineca.it
RIF a cineca.it
trovato per pippo.cineca137.205.88.00
pippo.cineca.Server di
Dominio
Server
Dominio
Secondari
Server
Dominio
Secondari
Sistemi di Nomi e RPC- 10
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)
Sistemi di Nomi e RPC- 11
DNS - informazioni Un server mantiene un record dinamico per ogni risorsa
(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 Valore 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
Sistemi di Nomi e RPC- 12
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
Sistemi di Nomi e RPC- 13
> 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
Sistemi di Nomi e RPC- 14
> 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
Sistemi di Nomi e RPC- 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
Sistemi di Nomi e RPC- 16
SISTEMA DI NOMI • generalità
varietà di nomi • definizioni multiple della stessa entità
varietà di nomi per lo stesso oggetto con mapping come corrispondenza capace di traslare
• distribuibilità uso di direttori partizionati o replicati
• user-friendliness
Processo
Nome di utente
Nome di sistema
Porte di processo
Porte di comunica-zione
Computer_id
Gateway 1
Computer 2A Computer 3A
Gateway 2
Route
Computer 1C Computer 2C
Gateway 3
Processo
Nome di utente
Nome di sistema
Porte di processo
Porte di comunica-zione
Computer_id
Network B
Computer 2B
Computer 1B
Computer 3B
Computer 1AComputer 1B
Nome delprocesso
Nome delprocesso
Indirizzo
Indirizzo
Network A
Presenza di molti livelli di nomi
Sistemi di Nomi e RPC- 17
CARATTERISTICHE DEL SISTEMA DI NAMING Contesti di definizione dei nomi • Uso generalizzato del nome nei diversi contesti e
strumenti • livelli di nomi diversi e relative funzioni di mapping • minimizzazione dei servizi di naming • interazione con contesti di validità dei nomi • replicazione
nomi che consentano la replicazione di oggetti • possibilità di riallocazione (bilanciamento)
uso di nomi che consentano il movimento di oggetti • multicast e broadcast
definizione di gruppi di oggetti e di azioni sui gruppi Esempi di nomi
uso esplicito del nome o dell'indirizzo: oggetto X o all'indirizzo X per contenuto, ossia per l'oggetto con valori di
attributi: oggetto il cui campo Z vale Y (o in relazione ad un valore: Z < 34) uso di una forma esplicita: tutti i miei files identificatore broadcast: tutti gli oggetti identificatore di gruppo: tutti il gruppo Z identificatore di cammino o route: oggetto che si trova seguendo il cammino K in relazione ad alcune delle specifiche precedenti: tutti gli oggetti determinati sopra
Sistemi di Nomi e RPC- 18
NAMING Problema fondamentale nel distribuito
necessità di ritrovare (cioè identificare) le altre entità nel sistema Complessità del problema (anche concentrato) e difficoltà di soluzioni generali
entità diverse eterogenee => livelli diversi di nomi più sistemi di naming presenti più livelli di naming nel sistema con contesti di visibilità più funzioni di trasformazione da nome all'entità nel sistema NOMI identificatore come • stringa di caratteri o • numero binario nomi esterni (nomi di utente) nomi interni (nomi di sistema) oggetti nome di utente (significativi) nome di sistema
Sistemi di Nomi e RPC- 19
LIVELLI DI NOMI NOME organizzato (Shock) in tre possibili livelli • nome LOGICO esterno • indirizzo FISICO • route sistema per la raggiungibilità nome specifica quale oggetto (entità) si riferisce denota la entità indirizzo specifica dove l'oggetto risiede riferisce dopo un collegamento (binding) route specifica come raggiungere l'oggetto Funzioni di corrispondenza MAPPING nomi ==> indirizzi indirizzi ==> route nomi scelti dall'utente indirizzi assegnati dal sistema
Sistemi di Nomi e RPC- 20
NAMING: problemi ambiguità con una sola forma di indirizzo
nomi di gruppo ==> non associati alla allocazione con possibilità di cambiamento della allocazione alle variazioni del gruppo indirizzi assoluti ==> non collegati alla allocazione indirizzi Ethernet
necessità di definire il mapping tra livelli di nomi diversi Indirizzi come tramite tra nomi e route
nomi ==> statici route ==> dinamici
indirizzi consentono il mapping NOME oggetto linguistico che distingue un oggetto in
una collezione di oggetti (dominio) denotazione Proprietà NOMI GLOBALI O LOCALI NON AMBIGUITÀ nomi unici nomi multipli per lo stesso oggetto (alias) NOMI STATICI E DINAMICI NOMI E CARDINALITÀ nomi specifici nomi di gruppo
Sistemi di Nomi e RPC- 21
SPAZIO DEI NOMI piatto (flat)
nessuna struttura partizionato
gerarchia e contesti (DNS) deis33.cineca.it
descrittivo
con riferimento ad una struttura di oggetto uso di attributi (OSI X.500) username e password attributi con liste di valori (rigidi o meno)
Nomi di gruppo
un valore di attributo identifica una lista di nomi Esempio: sistema di naming piatto statico e globale ==> assoluto per sistemi con indipendenza dalla comunicazione si cambiano le tabelle di indirizzamento
Sistemi di Nomi e RPC- 22
COMPONENTI DI UN SERVIZIO DI NAMING • Name Server (anche più di uno) • Comunicazione con il name server • Gestione tabelle e coordinamento • Gestione dei nomi veri e propri (coordinamento) Name server Oggetti con tuple di attributi con operazioni Query
ricerca un oggetto AddTuple / DeleteTuple
aggiungi/togli una tupla dal server ModifYTuple modifica una tupla Enumerate lista tutte le tuple, una alla volta
Realizzazione con
UNICO SERVIZIO VS. AGENTI MULTIPLI Il servizio può essere centralizzato, distribuito (replicato)
COMUNICAZIONE considerata tra servitori/agenti (e tra loro) - datagrammi - connessioni - RPC
GESTIONE TABELLE E COORDINAMENTO problemi di - consistenza - reliability
Sistemi di Nomi e RPC- 23
Gestione dei nomi veri e propri Due temi fondamentali - Distribuzione dei nomi - Risoluzione dei nomi Nomi
dipendenti dalla locazione dipendenti dalla autorità (uso di domini) organizzati in gerarchia (uso di un albero unico riconosciuto di domini) liberi da struttura uso di un insieme di attributi e del loro valore
Distribuzione dei nomi I nomi sono mantenuti in oggetti che hanno la responsabilità ==> autorità partizionamento tra i server responsabili Come dividere la gestione e il mantenimento?
Clustering Algoritmico (hash) Sintattico (pattern matching) Basato su Attributi (tuple)
Risoluzione dei nomi - trovare la autorità corretta - verificare le autorizzazioni alla operazione - eseguire la operazione
Ogni nodo specifica i name server noti Limitazione delle comunicazioni tra i server
Sistemi di Nomi e RPC- 24
IMPLEMENTAZIONE (VEDI DNS) USO DI CONTESTI E LOCALITÀ Si distribuisce e risolve nel contesto locale Si ricorre ad altri contesti solo in caso sia necessario
STRATEGIE DI COORDINAMENTO TRA SERVER
Nameagent
Name
Name
Name
Nameserver
server
server
server
Risoluzione ricorsiva
Nameagent
Name
NameName
Nameserver
serverserver
server
Risoluzione iterativa
Nameagent
Name
NameName
Nameserver
serverserver
server
Risoluzione transitiva
Sistemi di Nomi e RPC- 25
Altri sistemi di nomi OSI X.500 - Servizio di Direttorio e di Nomi partizionato e decentralizzato standard e omogeneo CCITT definisce X500 come "una collezione di sistemi aperti che cooperano per mantenere un database logico di informazioni sugli oggetti del mondo reale. Gli utenti della Directory possono leggere o modificare l'informazione, o parte di essa, solo se hanno i privilegi necessari" Per superare i limiti di DNS
CCITT ISO TITLE
X.500 9594-1 Overview of Concepts, Models and Services
X.501 9594-2 Models
X.509 9594-8 Authentication Framework
X.511 9594-3 Abstract Service Definition
X.518 9594-4 Procedures for Distributed Operation
X.519 9594-5 Protocol Specifications
X.520 9594-6 Selected Attribute Types
X.521 9594-7 Selected Object Classes
X.525 9594-9 Replication
X.500 organizza un albero logico per il Directory Information Base DIB, chiamato Directory Information Tree (DIT) L'albero è costruito in base al valore di attributi ATTRIBUTI DEL TUTTO LIBERI ORGANIZZAZIONI BASATE SUL CONTENUTO RICERCHE ANCHE SU VALORI CONGIUNTI DEGLI ATTRIBUTI
Sistemi di Nomi e RPC- 26
Ad esempio Root node
Country =AU Country=US Country=It
Organization =ABC Ltd
Locality =New York
Organization =ABC Ltd
Org. Unit =Sales
Common Name= F. Jones
Org. Unit =Production
Common Name= A. Chew
Common Name= Fax Machine
Common Name= J. Smart
Ogni entry si ritrova attraverso diverse notazioni Distinguished Name (DN) che identifica univocamente
l'oggetto all'interno del DIT Relative Distinguished Name (RDN) che definisce
univocamente un oggetto all'interno di un contesto DN fa da chiave per identificare in modo unico un nodo che può essere pensato come una tupla di coppie
attributo = valore ad esempio country, organization, organization unit, common name
Le ricerche possono essere fatte in modo globale o contestuale per un DN ma anche per contenuto dei nodi, in base: ad un attributo o ad un filtro generalizzato portando ad un nodo risultato o più nodi
Sistemi di Nomi e RPC- 27
RICERCHE su DIRETTORI X500 I direttori sono sistemi di nomi molto liberi come struttura e ricerca I filtri sono molto liberi, ad esempio, intesi come condizione logica sugli attributi CN=Corradi AND C=Italy anche con espressioni regolari email=*hotmail* anche con condizioni aritmetiche (age >18) AND (cookies <10) si possono applicare anche su scope limitati (contesti o sottoalberi) Le operazioni consentite sono molte La prima è il legame (bind) con il directory poi ricerche frequenti e cambiamenti molto meno frequenti La interfaccia con il direttorio anche molto complessa
durata delle operazioni
Sistemi di Nomi e RPC- 28
Ricerca sul direttorio (OSI X.500)
La ricerca avviene attraverso agenti: DUA, directory user agent tramite per fare richieste DSA, directory system agent che mantiene informazioni X.500 di un contesto DSP, directory system protocol per scambiare informazioni tra DSA DAP, Directory Access Protocol protocollo di accesso al direttorio usato da DUA si crea una connessione e poi si fanno operazioni di lettura, confronto, ricerca, lista delle entità Tecniche di ricerca ricorsive ed iterative LDAP, Lightweight Directory Access Protocol usato per infrastrutture di certificazione e verifiche
Sistemi di Nomi e RPC- 29
DIRECTORY E NON DATABASE obiettivo di un directory è memorizzare informazioni su un insieme di risorse per un ambiente di calcolo evitando duplicazioni di informazioni problemi di sincronizzazione consentendo una capacità espressiva ampia ed estendibile una gestione anche molteplice con più autorità per parti una sicurezza anche partizionata e differenziata Al contrario di un database (o più database)
• si associano gli attributi con i singoli oggetti • gli oggetti sono indipendenti tra di loro (e possono
essere diversi) • si considera la relazione di contenimento come base
della organizzazione • si possono avere proprietà di accesso differenziate
per i singoli oggetti e anche attributi • si ottimizza considerando un numero elevato di letture
in confronto alle scritture
• Necessità di un protocollo standard unificato per accedere alle informazioni,
• esprimere le specifiche di accesso, ed • estrarre informazioni in modo efficace
Sistemi di Nomi e RPC- 30
USO DI DIRECTORY i directory sono tipicamente usati (visto il costo) per la rappresentazione di persone, risorse, servizi, server, ... In generale, per informazioni concettuali che rappresentano la gestione di oggetti comuni in un ambiente condiviso i certificati per autenticare e autorizzare accesso
MANAGEMENT DELLE RISORSE In un sistema di gestione in cui consideriamo una molteplicità di gestori con autorità e responsabilità anche non completamente note
si usano DIRECTORY per
• localizzare i diversi gestori e le loro politiche • trattare i problemi di domini incrociati (cross-domain) • ritrovare le proprietà delle risorse • ritrovare le proprietà dei gestori delle risorse
I costi sono dipendenti dal numero dei nodi (e attributi) motivati anche dalle proprietà di QoS offerto (affidabilità e disponibilità)
Sistemi di Nomi e RPC- 31
SVILUPPO DEI SISTEMI DI NOMI Due forme di evoluzione Protocolli di Directory Protocolli di Discovery Considerando una entità che possa avere attributi con lente variazioni e attributi con variazioni veloci Directory
soluzioni di nomi globali servizi completi e complessi costo elevato delle operazioni
Discovery
soluzioni di nomi locali servizi essenziali e funzioni limitate costo limitato adatto a variazioni rapide
Ad esempio: Un utente generico che si muova in un sistema globale vuole avere accesso a
informazioni globali, come descrizione dei dispositivi, delle preferenze proprie del suo profilo, delle sue firme digitali e PKI delle sue sorgenti di informazioni, ecc.
informazioni locali, come descrizione delle risorse locali dei gestori presenti, ecc.
Sistemi di Nomi e RPC- 32
Protocolli di Directory Un servizio di directory
garantisce le proprietà di replicazione, sicurezza, gestione multiserver, ...
supporto per memorizzare le informazioni organizzate prevedendo molti accessi in lettura e poche variazioni UPnP (Universal Plug-and-Play) Standard vicino alle architetture Microsoft Servizi di Nomi basati su variazioni di DAP (o LDAP)
Windows2000 propone Active Directory come un servizio di direttori integrato nel e per il sistema operativo
Salutation Service Location Protocol (RFC 2165)
• si possono registrare servizi diversi • i servizi vengono divisi in località distinte • i servizi vengono protetti in diversi modi • interfacce compatibili con i browser (Web) • uso di sistemi di nomi URL
Le operazioni definite e implementate permettono di fare ricerche molto evolute sulle informazioni (memorizzate in modo globale) e compatibili con la maggior parte degli strumenti e dei sistemi di nomi più diffusi
<http, research, homepage> <printer, local, postscript>
Ci sono già implementazioni: Cisco, Apple, Novell area del Mobile Computing
Sistemi di Nomi e RPC- 33
Protocolli di Discovery Computazione distribuita e cooperativa in ambito locale Una unità deve ritrovarne altre, in modo veloce e economico si prevedono azioni come il broadcast e solleciti periodici
un servizio di discovery definisce e standardizza come si possano ritrovare altre entità correntemente visibili (informazioni di località delle risorse)
JINI protocollo Java per il discovery (appliances) Si vuole rispondere alle esigenze di chi arriva in un contesto e vuole operare senza conoscenze predefinite Protocolli di lookup
Jini Service
Jini Client
Lookup Service
Rete Locale
1 Richiesta Multicast
2 Risposta del Lookup Service
1 Richiesta Multicast
2 Risposta del Lookup Service
Il server può passare (tramite lookup) al cliente: • anche codice (che si può eseguire localmente)
integrazione con codice mobile • riferimento al server (da interrogare in remoto - RMI) Start up con multicast in ambiente locale Il discovery server verifica la presenza delle risorse ad intervalli opportuni
Sistemi di Nomi e RPC- 34
INDIRIZZI (NOMI DI SISTEMA) forma intermedia tra nome e route
NOMI ==> entità INDIRIZZI ==> orientati alla comunicazione con oggetto attraverso il BINDING usato per generare la route Quindi, l'indirizzo serve per la comunicazione con l'entità vedi OSI o comunicazione attraverso porte
Nome
Indirizzo
Route
Mapping
ad un passo
Mapping
Mapping
(routing)
(direttorio)
Oggetto dicomunicazion
INDIRIZZI come per i nomi piatti o partizionati
statici o dinamici individuali o di gruppo
MAPPING ad un unico passo, a più passi routing per nome (by name) routing per indirizzo (by address) Internet
Nomi di alto livello, convertiti in nomi DNS Nomi di IP di dominio convertiti in IP Routing fatto a livello di IP
Sistemi di Nomi e RPC- 35
NOMI DI SISTEMA Necessità di ottenere, a livello di sistema, dei nomi che siano unici o nomi che consentano un accesso protetto
NOMI UNICI Identificatori non strutturati o strutturati VANTAGGI DELLA NON STRUTTURAZIONE • Facilità di memorizzazione • Nomi assoluti ed uniformi (indipendenza dalla allocazione) • Composizione di oggetti e tipaggio SVANTAGGI DELLA NON STRUTTURAZIONE • difficoltà di creare nomi unici globali • difficoltà per oggetti con versioni e replicazione NOMI UNICI in un sistema distribuito ottenuto con - concatenazione gerarchica nome_nodo @ nome_oggetto nome_server @ nome_oggetto (a server) nomi di lunghezza variabile e non trasparenza - approccio uniforme (a priori) partizione dei nomi globali per fornire ogni nodo con i
propri identificatori scelta locale dei nomi più adatti e riassegnamento - concatenazione ottenuta con il dominio ed il tempo di generazione nome nodo | tempo_fisico
Sistemi di Nomi e RPC- 36
IDENTIFICAZIONE DEL SERVER Si usano porte per ritrovare il server per ogni oggetto di interesse
{PortAddress, local_unique_ID}
IDENTIFICAZIONE DELL'OGGETTO Organizzazione in più fasi di ricerca attraverso binding statico o name server o broadcast Prima accesso al server Poi identificazione dell'oggetto
oggetto
Server local-unique-ID
sistema IPC
mappingroute
mapping nel
server
identificatore locale
tabelle dirouting
distribuite
contesto locale
(distribuito)
Uso di cache
Sistemi di Nomi e RPC- 37
REMOTE PROCEDURE CALL (RPC) estensione del normale meccanismo di chiamata a procedura, adatta per il modello cliente servitore IDEA per uniformare programmi concentrati e distribuiti APPROCCIO linguistico:
il cliente invia la richiesta ed attende fino alla risposta del servitore stesso
A differenza della chiamata a procedura locale - i processi non condividono lo spazio di indirizzamento - i processi hanno vita separata - possono accadere malfunzionamenti, sia ai nodi, sia
alla interconnessione RPC consente di considerare anche il controllo di tipo da livello di linguaggio del cliente al servitore trattamento automatico degli argomenti di ingresso e di uscita dal cliente al servitore, e viceversa marshalling
Nodo A Nodo B
Cliente Server call
risultato callwait
ricezione
ritorno
Sistemi di Nomi e RPC- 38
RPC Birrel Nelson (1984) usate in Xerox, Spice, Sun, HP, etc. PROPRIETÀ
trasparenza approccio locale e remoto uniformità totale è impossibile (guasti)
controllo di tipo e parametrizzazione lo stesso controllo di tipo e dei parametri
controllo concorrenza e eccezioni binding distribuito possibile trattamento degli orfani
recovery in caso di fallimento: orfano chi resta
MODELLO CLIENTE/SERVITORE invocazione di un servizio remoto con parametri tipati, valore di ritorno Modello di base: P.B. Hansen (Distributed Processing) Nelson Birrel
Host Host A Host B
Programma
Proceduralocale
Programma clien t
Proceduraserver
Connessionedi
rete
Sistemi di Nomi e RPC- 39
RPC come astrazione dello scambio messaggi o comunicazione CLIENTE SERVITORE send (a chi) get-request <operazione> wait send-reply Progetto Athena MIT, ITC CMU, ...
PRIMITIVE dalla parte del cliente call servizio (nodoservitore, argomenti, risultato) dalla parte del servitore due possibilità: - il servizio svolto da un unico processo sequenziale - il servizio è un processo indipendente, generato per
ogni richiesta (approccio implicito)
Schema NON TRASPARENTE
Client Server
Programma client Processo server
callrpc()
esecuzione r ichiestachiamata
servizio
r itorno
richiesta completatar isposta
Sistemi di Nomi e RPC- 40
Modello con trasparenza Birrel Nelson: uso di stub ossia di interfacce per la trasparenza che trasformano la richiesta da locale a remota
Client Server
Programma client
Stub del client
RPC run-time
Procedura server
Stub del server
RPC run-time
Interfaccia
Comunicazione di rete
Interfaccia
Il cliente invoca uno stub, che si incarica del trattamento dei parametri e della richiesta al supporto run-time, per il trasporto della richiesta Il servitore riceve la richiesta dallo stub relativo, che si incarica del trattamento dei parametri dopo avere ricevuto la richiesta pervenuta dal trasporto. Al completamento del servizio, lo stub rimanda il risultato al cliente
Uso di STUB Sono componenti che servono a superare i problemi di trasparenza Lo sviluppo con STUB prevede trasparenza gli stub sono in genere prodotti 'automaticamente'
L'UTENTE PROGETTA SOLO LE PARTI APPLICATIVE
Sistemi di Nomi e RPC- 41
GLI STUB operazione(parametri) stub cliente: <ricerca del servitore> <marshalling argomenti> <send richiesta> <receive risposta> <unmarshalling risultato> restituisci risultato fine stub cliente;
stub servitore: <attesa della richiesta> <unmarshalling argomenti> invoca operazione locale ottieni risultato <marshalling del risultato> <send risultato> fine stub servitore;
operazione(parametri) In aggiunta, il controllo della operazione ed eventuali azioni di ritrasmissione (entro un tempo di durata massima)
Cliente
Clientestub
RPCprotocollo
RisultatoArgomenti
MSGMSG
Server
Serverstub
valoreArgomenti
RPCprotocollo
richiesta rispostaMSGMSG
richiesta risposta
Risultatovalori
TCP/IP
Sistemi di Nomi e RPC- 42
Passaggio dei parametri passaggio per valore o per riferimento
Trattamento dei parametri per valore
impaccamento dei parametri e disimpaccamento marshalling ==> dipende dal linguaggio utilizzato unmarshalling Problema della rappresentazione dei dati Se si vuole passare un tipo primitivo o un’entità con certi valori privati marshalling e unmarshalling per la presentazione Per un tipo utente costruito e dinamico, ad esempio, una lista o un albero
si deve muoverla e ricostituirla sul server per poi riportarla sul nodo iniziale (?) e la memoria dinamica (?)
Passaggio parametri nel caso di valore ==> trasferimento e visita (poi valore perso) nel caso di riferimento ==>
uso di oggetti che rimangono nel nodo di partenza e devono essere identificati in modo unico nell'intero sistema
Se si vuole riferire un’entità del cliente si passa il riferimento alla stessa entità da riferire con RPC da nodi remoti
Per esempio, un oggetto del nodo di partenza che sia già in uso deve potere essere riferito dal nodo servitore
PASSAGGIO DEI PARAMETRI
Sistemi di Nomi e RPC- 43
passaggio per valore e per riferimento nel caso di riferimento ==>
uso di oggetti confinati che sono identificati in modo unico nell'intero sistema
Trattamento dei parametri
impaccamento dei parametri e disimpaccamento marshalling ==> dipende dal linguaggio utilizzato unmarshalling
Exception handling problemi tipici dipendenti dalla distribuzione e loro gestione
In un caso generale, una RPC può: • produrre il servizio con successo • produrre insuccesso e determinare una eccezione In genere, si specifica la azione per il trattamento anomalo in un opportuno gestore della eccezione Si possono prevedere più gestori a seconda dell'evento anomalo. Inoltre, si può anche inserire l'eccezione nello scope di linguaggio CLU (Liskov) a livello di invocazione della RPC MESA (Cedar) a livello di messaggio
Sistemi di Nomi e RPC- 44
Interface Definition Language IDL Definizione di linguaggi per la descrizione delle operazioni remote per la specifica del servizio FIRMA del SERVIZIO (SIGNATURE) Un IDL deve consentire:
• identificazione (unica) del servizio tra quelli possibili uso di nome astratto del servizio versioni diverse del servizio
• definizione astratta dei dati da trasmettere in input ed output uso di un linguaggio astratto di definizione dei dati (uso di interfacce, con operazioni e parametri)
• possibili estensioni: linguaggio con ereditarietà ambiente con binder ed altre entità
Dalla definizione del linguaggio IDL strumenti per lo sviluppo automatico di parte dei programmi direttamente dalla specifica astratta SUN XDR OSF DCE IDL ANSA ANSAware HP NCS IDL CORBA IDL
Sistemi di Nomi e RPC- 45
XDR eXternal Data Representation Il formato XDR definisce le operazioni remote e tutto quello che è necessario conoscere per la generazione di stub file msg.x program MESSAGEPROG { version MESSAGEVERS { int PRINTMESSAGE(string) = 1; } = 1; } = 0x20000013;
file fileremoto.x /* definizioni tipiXDR */ const MAXNAMELEN=256; const MAXSTRLEN=255; struct r_arg { string filename<MAXNAMELEN>; int start; int length;}; struct w_arg { string filename <MAXNAMELEN>; opaque block<>; int start;}; struct r_res {int errno; int reads; opaque block<>;}; struct w_res {int errno; int writes;}; /* definizione di programma RPC */ program ESEMPIO { version ESEMPIOV { int PING(int)=1; r_res READ(r_arg)=2; w_res WRITE(w_arg)=3; }=1; }=0x20000020;
Sistemi di Nomi e RPC- 46
AFFIDABILITÀ (Reliability) Malfunzionamenti - perdita di messaggio di richiesta o di risposta - crash del nodo del cliente - crash del nodo del servitore In caso di crash del servitore, prima di fornire la risposta il cliente può: • aspettare per sempre; • time-out e riportare una eccezione al cliente; • time-out e ritrasmettere (uso identificatori unici); Operazioni idempotenti che si possono eseguire un numero qualunque di volte
con lo stesso esito Semantica di funzionamento
may-be time-out per il cliente at-least-once time-out e ritrasmissioni at-most-once tabelle delle azioni effettuate exactly-once e l'azione fatta fino alla fine
In caso di crash del cliente, si devono trattare orfani - sterminio: ogni orfano risultato di un crash viene
distrutto - terminazione a tempo: ogni calcolo ha una scadenza,
oltre la quale è automaticamente abortito - reincarnazione (ad epoche): tempo diviso in epoche;
tutto ciò che è relativo alla epoca precedente è obsoleto
Sistemi di Nomi e RPC- 47
SEMANTICA della comunicazione MAY-BE UN SOLO INVIO il messaggio può arrivare o meno PROGETTO BEST-EFFORT IP UDP non si fanno azioni per garantire affidabilità AT-LEAST-ONCE PIÙ INVII AD INTERVALLI il messaggio può arrivare anche più volte a causa
della duplicazione dei messaggi dovuti a ritrasmissioni
==> semantica adatta per azioni idempotenti in caso di insuccesso nessuna informazione implementazione PROGETTO RELIABLE (AL MITTENTE) il cliente fa ritrasmissioni (quante?, ogni quanto? ...) il server non se ne accorge
Semantica at-least-once
Servitore
t
e
m
p
o
Cliente
send
receive
time-out
time-outoperazione
operazione rieseguita
il cliente si preoccupa della affidabilità Si noti la durata della azione Il cliente decide (in modo unilaterale) la durata massima
Sistemi di Nomi e RPC- 48
AT-MOST-ONCE PIÙ INVII AD INTERVALLI STATO SUL SERVER cliente e servitore lavorano coordinati per
ottenere garanzie di correttezza e affidabilità il messaggio, se arriva, viene considerato al più una volta ==> semantica che non mette vincoli sulle azioni
conseguenti in caso di insuccesso nessuna informazione implementazione TCP PROGETTO RELIABLE per cliente e servitore il cliente fa ritrasmissioni (quante?, ogni quanto? ...) il server mantiene uno stato per riconoscere i messaggi già ricevuti e per non eseguire azioni più di una volta
Semantica at most-once
ServitoreCliente
send
receive
time-out
time-out
operazione1
operazione1 non rieseguita
tabella delle operazione
già eseguite (da non rifare)t
e
m
p
o
STATO MANTENUTO PER UN CERTO TEMPO Si noti la durata della azione delle due parti Il cliente decide la durata massima della propria azione Il server mantiene uno stato per garantire correttezza Per quanto tempo i pari mantengono lo stato della interazione? E se uno fallisce?
Sistemi di Nomi e RPC- 49
Semantica per at-most e at-least Se le cose vanno male manca il coordinamento e non sappiamo cosa sia successo EXACTLY-ONCE O ATOMICITÀ Al termine sappiamo se l'operazione è stata fatta o meno
i pari lavorano entrambi per ottenere il massimo dell'accordo e della reliability il messaggio arriva una volta sola oppure
il messaggio o è arrivato o non è stato considerato da entrambi ==> semantica molto coordinata sullo stato PROGETTO con conoscenza dello stato finale AFFIDABILITÀ e COORDINAMENTO massimo semantica TUTTO o NIENTE
In caso le cose vadano bene il messaggio arriva una volta e una volta sola viene trattato, riconoscendo i duplicati (tutto) In caso le cose vadano 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, il tutto può essere riportato indietro (niente) Completo coordinamento delle azioni Durata delle azioni non predicibile
Se uno dei due fallisce, bisogna aspettare che abbia fatto il recovery (o qualcuno aspetta al suo posto) Entrambi sanno realmente come è andata (tutto o niente)
Sistemi di Nomi e RPC- 50
FASI compilazione binding trasporto controllo rappresentazione dei dati
problemi in ambiente eterogeneo Le scelte sono diverse scelta pessimistica e statica
La compilazione potrebbe risolvere ogni problema e forzare un binding statico
scelta ottimistica e dinamica
Il binding dinamico consente di ridirigere le richieste sul gestore più scarico o presente in caso di sistema dinamico
L'uso della comunicazione è intrinseco tanto più veloce, tanto meglio
Il controllo consente anche di usare gli stessi strumenti per funzioni diverse, con maggiore asincronicità e maggiore complessità
necessità di traslazione dei dati tanto più veloce, tanto meglio bilanciata con la ridondanza che viene ritenuta necessaria
Sistemi di Nomi e RPC- 51
Trattamento del binding legame tra cliente e servitore
STATICO vs. DINAMICO
due fasi: - servizio, il cliente specifica a chi vuole essere
connesso, come nome del servizio (NAMING) - indirizzo, il cliente deve essere collegato al servitore
che fornisce il servizio (ADDRESSING) NAMING
si può risolvere attraverso un numero associato staticamente alla interfaccia del servizio
ADDRESSING DINAMICO 1) si può risolvere con un multicast o broadcast
attendendo solo la prima risposta e non le altre ESPLICITAMENTE dai processi 2) uso di un name server che registra tutti i servitori IMPLICITAMENTE dall'agente esterno
Azioni sulle tabelle di binding registrazione, aggiornamento, eliminazione
Name Server
Programma cliente
Stub del client
RPC run-time
Procedura servitore
Stub del server
RPC run-time
Interfaccia
Comunicazione di rete
Interfaccia
Sistemi di Nomi e RPC- 52
Binding Dinamico La chiamata può andare a buon fine dopo un collegamento statico o dinamico
il binding può avvenire meno frequentemente delle chiamate stesse in genere, si usa lo stesso binding per molte richieste e chiamate allo stesso server
Binder (Broker, Name Server, etc.) entità che consente il collegamento tra clienti e servitori possibilità di tenere conto dei servizi operazioni per un binder possono consentire anche agganci più liberi lookup (servizio, versione, &servitore) register (servizio, versione, servitore) unregister (servizio, versione, servitore)
Il nome del servitore (servitore) può essere dipendente dal nodo di residenza o meno: se dipendente, allora una variazione deve essere comunicata al binder
BINDING come servizio coordinato Uso di binder multipli per limitare overhead
Inizialmente i clienti usano un broadcast per trovare il binder più conveniente
Uso di cache ai singoli clienti o ai singoli nodi
Sistemi di Nomi e RPC- 53
GESTORE del Binding Dinamico La chiamata sono, almeno in generale, dinamiche e richiedono un gestore opportuno
Presenza di gestori Si possono ipotizzare gestori con politiche molto diverse Unico gestore centrale Più gestori isolati (ognuno gestisce una partizione) Più gestori coordinati A secondo del costo che si vuole sopportare La maggior parte dei sistemi di RPC e derivati tende ad ipotizzare NON un unico gestore centralizzato MA più gestori partizionati e non coordinati Allocazione del gestore In caso di gestori molteplici, ogni gestore tende ad essere responsabile
di una area di gestione Tipicamente il gestore risiede su un nodo e gestisce le operazioni di quel nodo I server del nodo si registrano presso il gestore locale I clienti devono accedere al gestore prima di arrivare al servizio sul nodo stesso