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

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 com dec edu purdue cc cs ecn gov nfs us cc reston xinu Radice innominata it unibo deis cineca cs deis33 Anche alias deis33 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 COM EDU GOV MIL NET ORG ARPA INT codice nazionale Significato Organizzazioni commerciali Istituzioni per l'istruzionre Istituzioni governative Gruppi militari Maggiori centri di supporto alla rete Organizzazioni diverse dalle precedenti Dominio temporaneo dell'arpanet (obsoleto) Organizzazioni internazionali (schema geografico) 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 - 1 Sistemi di Nomi - 2

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 Generic Countries 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à int com edu gov mil org net it uk fr sun yale acm ieee cineca unibo unims inria java cs eng jack jill deis cs eng Il tutto è organizzato a ZONE, ogni zona riconosce una autorità che fornisce le corrette corrispondenze suddivisione in zone geografica o di organizzazione Generic Countries a livello di API si passa il riferimento da mappare ad un resolver che - o conosce già la corrispondenza (cache) - o la trova attraverso richiesta C/S a un name server int com edu gov mil org net sun yale acm ieee cineca unibo it uk unims fr inria I DNS name server sono organizzati come agenti per ottenere informazioni reciprocamente (dalla più corretta autorità) java cs eng jack jill deis cs eng Sistemi di Nomi - 3 Sistemi di Nomi - 4

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) trova pippo.cineca.it resolver Server Secondari Dominio Server di Dominio client Gestore deis.unibo.it Server Secondari Dominio RIF a cineca.it it RIF a it unibo.it cineca.it pippo.cineca.it trovato per pippo.cineca.it 137.205.88.00 Sistemi di Nomi - 5 Sistemi di Nomi - 6

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 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 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 3 in-addr 137 1 204 1 57 arpa 255 255 ipotetica radice 255 1 33 255 Sistemi di Nomi - 7 Sistemi di Nomi - 8

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 h., 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 Sistemi di Nomi - 9 Sistemi di Nomi - 10

> 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 - 11 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 modello di naming e sistemi di nome conoscenza reciproche delle entità / servizi Sistemi di Nomi - 12

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 Sistemi di Nomi - 13 Sistemi di Nomi - 14

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) com edu gov us it Sistema di NOMI generalità varietà di nomi definizioni multiple della stessa entità varietà di nomi per lo stesso oggetto con mapping capace di traslare distribuibilità uso di direttori partizionati o replicati user-friendliness Nome del processo Indirizzo Network A Computer 2A Computer 1A Processo Gateway 1 Nome di utente Nome di sistema Porte di processo Porte di comunicazione Computer_id Computer 3A Gateway 2 Route Nome del processo Indirizzo Computer 1B Processo Network B Nome di utente Nome di sistema Porte di processo Porte di comunicazione Computer_id Computer 1B Computer 2B Computer 3B dec purdue nfs cc unibo cineca Computer 1C Computer 2C Gateway 3 cc cs ecn reston deis dipmat xinu Presenza di molti livelli di nomi Sistemi di Nomi - 15 Sistemi di Nomi - 16

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 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 - 17 Sistemi di Nomi - 18

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 Sistemi di Nomi - 19 Sistemi di Nomi - 20

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 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 l operazione ogni nodo specifica i name server noti limitazione delle comunicazioni tra i server Gestione dei nomi veri e propri Sistemi di Nomi - 21 Sistemi di Nomi - 22

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" Ad esempio Root node Country =AU Country=US Country=It Organization = ABC Ltd Locality = New York Organization = ABC Ltd Per superare i limiti di DNS Org. Unit = Sales Common Name = A. Chew Org. Unit = Production 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 - 23 Common Name = F. Jones Common Name = J. Smart Common Name = Fax Machine 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 - 24

RICERCHE su DIRETTORI X.500 I direttori sono sistemi di nomi molto liberi come struttura e ricerca Ricerca sul direttorio (OSI X.500) 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 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 - 25 Sistemi di Nomi - 26

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 Sistemi di Nomi - 27 Sistemi di Nomi - 28

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 1 Richiesta Multicast 1 Richiesta Multicast Jini Service 2 Risposta del Lookup Service Rete Locale Lookup Service 2 Risposta del Lookup Service Jini Client 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 - 29 Sistemi di Nomi - 30