anche librerie dinamiche conoscenza reciproca modello di ... · a livello di API si passa il...

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


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


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


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


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


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


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à)


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


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


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)


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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à)


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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;


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


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


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?


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)


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


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


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


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

anche librerie dinamiche conoscenza reciproca modello di ... · a livello di API si passa il...

Documents

Transcript of anche librerie dinamiche conoscenza reciproca modello di ... · a livello di API si passa il...