.. meta:: :language: it :description language=it: naming :description language=en: naming :keywords: distributed system, naming :author: Luciano De Falco Alfano .. index:: naming .. _ref_naming: Naming ========= .. contents:: :local: *Lezione del 2019-05-02 gio*. Il concetto di **naming** deriva dalla necessità di identificare i punti d'accesso ad una entità. Un punto d'accesso ha anche un indirizzo, ma gli indirizzi di solito sono difficili da ricordare, non vi è trasparenza nell'accesso e può cambiare nel tempo. Si pensi ad esempio alla necessità di comunicare tramite un indirizzo di rete. Ricordare gli indirizzi IP (per non parlare dei MAC) associati alle entità che devono comunicare sarebbe estremamente difficile. Per i motivi predetti è meglio identificare un punto d'accesso tramite un *nome* indipendente dall'indirizzo, ottenendo l'indipendenza dalla locazione. Ma la sola assegnazione di un nome non risolve il problema. Per comunicare ci serve comunque l'indirizzo dell'entità. Quindi abbiamo la necessità di avere un meccanismo che, dato un nome, ci indichi il relativo indirizzo associato. Questo meccanismo è detto **naming resolution** (risoluzione del nome). Quindi il *nome* identifica l'entità. E la *risoluzione del nome* permette l'accesso all'entità di nome indicato tramite l'indirizzo ad esso associato. Quindi, per risolvere i nomi, è necessario implementare un **naming system**. Esistono più strategie nella gestione dei nomi. Flat naming ------------- Nel caso di **flat naming** i nomi sono decisi in modo tale da rappresentare univocamente le entità. In questo caso, dato il solo nome, è possibile localizzare l'entità che lo possiede tramite: * *broadcasting*, inviando la richiesta a tutti coloro sono in ascolto; esempio tipico è lo Address Resolution Protocol (ARP); * *multicasting*, inviando la richiesta solo a determinati gruppi di host. La tecnica del *broadcasting* è semplice da implementare, ma diviene inefficiente al crescere delle dimensioni della rete. Forward pointers ------------------ Se le entità da indirizzare sono mobili, è possibile individuarle utilizzando la tecnica dei *forward pointers*: quando l'entità si muove da *A* a *B*, lascia in *A* un riferimento alla sua nuova locazione in *B*. I *forward pointers* hanno uno svantaggio. Se l'entità si sposta molto, si lascia dietro una coda di puntatori molto lunga. Con relativi problemi di lentezza di attraversamento, e di pesantezza di manutenzione [#]_. Approccio Home-based ---------------------- Altro possibile sistema è l'approccio *home-based* di MIPv6, che abbiamo illustrato per i dispositivi mobili. Quindi presenza di un *home address* in un *home network* in cui è localizzato un *home agent*. Lo *home agent* reindirizza le chiamate al *care-of address* quando il dispositivo è al di fuori della *home network*. Approccio gerarchico distribuito (DNS) --------------------------------------- Altri possibili meccanismi di risoluzione dei nomi sono: * tabelle hash distribuite; * approccio gerarchico distribuito. Vediamo il secondo, particolarmente importante perché adottato dal DNS. Il Domain Name Service permette di associare un indirizzo IP ad un nome host, ma questo deve essere espresso secondo una morfologia gerarchica precostituita. In tal modo è possibile utilizzare un algoritmo distribuito per la risoluzione del nome, secondo lo schema gerarchico illustrato qui di seguito. .. image:: ./images/21_DNS.svg :align: center Come illustrato, alla base della gerarchia vi è il *root DNS server*, che è logicamente uno, ma fisicamente è un gruppo di 13 repliche. Tutte con le stesse informazioni. Questo per avere scalabilità. Ma qui la scalabilità è perseguita anche tramite la *distribuzione*, grazie alla gerarchia dei nomi. Infatti *root* conosce i nomi, e relativi indirizzi, dei server responsabili del primo livello: *com*, *edu*, *org*, *uk*, *it*, ... A loro volta i *top level domain server, (ad es. *com*) conoscono nomi ed indirizzi dei relativi host, e così via. Esistono due modi per interrogare il DNS: * *ricorsivo*; * *iterativo*. L'interrogazione del DNS con modalità *ricorsiva*, consiste nel chiedere la risoluzione del nome host al root name server, ed attendere da questo una risposta esaustiva. Se il root server conosce direttamente l'indirizzo del nome richiesto, lo invia come risposta. In caso contrario, inoltra la richiesta al top level domain di competenza. Quando riceve la risposta dal top leve domain server, la inoltra al richiedente. A sua volta il top level domain server avrà un comportamento analogo a quello del root server. L'interrogazione con modalità *iterativa* è radicalmente diversa. Anche in questo caso se il root server conosce direttamente l'indirizzo del nome richiesto, lo invia come risposta. Ma, in caso contrario, invia la richiedente l'indirizzo del top level domain di competenza. È compito del richiedente rivolgersi al top level domain server per chiedere nuovamente la risoluzione del nome. E così via. La modalità *ricorsiva* è più semplice per il richiedente. Ma ha il grosso svantaggio di caricare pesantemente i processi del DNS. Per questo motivo oggi si usa quasi esclusivamente la modalità *iterativa*. Quest'ultima è preferita, nonostante sia più complessa da attuare da parte del richiedente, perché i processi del DNS rispondono immediatamente, tornando la palla al richiedente. In tal modo il carico di lavoro per il DNS è più contenuto: non rimangono (milioni di) processi appesi, in attesa di una risposta che arriverà da parte del server autoritativo, e che dovrà essere inoltrata al richiedente. Si noti che, per ottenere la scalabilità, il DNS utilizza anche la cache, oltre la replica e la distribuzione. Se non è possibile attuare una implementazione distribuita, il modo normale di implemenare un servizo di name server è tramite server centralizzato. ---------------- .. [#] Solito problema, se un nodo intermedio deve sparire, prima deve passare opportunamente i suo puntatori.