Correzioni materiale sul resolver
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 6 Jun 2004 10:32:45 +0000 (10:32 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 6 Jun 2004 10:32:45 +0000 (10:32 +0000)
sockctrl.tex

index 5103df1..82f1c66 100644 (file)
 
 Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
 alla gestione dei socket, come la gestione della risoluzione di nomi e
-indirizzi, le impostazioni delle varie proprietà degli stessi, e le funzioni
-di controllo che vanno ad operare su di essi.
+indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
+socket, e le funzioni di controllo che permettono di modificarne il
+comportamento.
 
 
 \section{La risoluzione dei nomi}
 \label{sec:sock_name_resolution}
 
-Negli esempi precedenti abbiamo sempre identificato le singole macchine
-attraverso indirizzi numerici, sfruttando al più le funzioni di conversione
-elementari illustrate in sez.~\ref{sec:sock_addr_func} che permettono di
-passare da un indirizzo espresso in forma dotted decimal ad un numero. Vedremo
-in questa sezione le funzioni utilizzate per poter utilizzare dei nomi
-simbolici al posto dei valori numerici, e viceversa quelle che permettono di
-ottenere i nomi simbolici associati ad indirizzi, porte o altre proprietà del
-sistema.
+Negli esempi dei capitoli precedenti abbiamo sempre identificato le singole
+macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
+conversione elementare illustrate in sez.~\ref{sec:sock_addr_func} che
+permettono di passare da un indirizzo espresso in forma dotted decimal ad un
+numero. Vedremo in questa sezione le funzioni utilizzate per poter utilizzare
+dei nomi simbolici al posto dei valori numerici, e viceversa quelle che
+permettono di ottenere i nomi simbolici associati ad indirizzi, porte o altre
+proprietà del sistema.
 
 
 \subsection{La struttura del \textit{resolver}}
@@ -72,20 +73,25 @@ alla programmazione, ci
 vale la pena farne una panoramica. Originariamente la configurazione
 riguardava esclusivamente le questioni relative alla gestione dei nomi a
 dominio, e prevedeva solo l'utilizzo del DNS e del file statico
-\file{/etc/hosts}, il file di configurazione principale è
-\file{/etc/resolv.conf} e contiene in sostanza l'elenco dei server DNS da
-contattare, a cui si affianca \file{/etc/host.conf} per indicare l'ordine in
-cui eseguire la risoluzione dei nomi (se usare prima i valori di
-\file{/etc/hosts} o il DNS); tralasciamo i dettagli che si trovano nelle
+\file{/etc/hosts}. 
+
+In questo caso il file di configurazione principale è \file{/etc/resolv.conf}
+che contiene in sostanza l'elenco dei server DNS da contattare, a cui si
+affianca il file \file{/etc/host.conf} il cui scopo principale è indicare
+l'ordine in cui eseguire la risoluzione dei nomi (se usare prima i valori di
+\file{/etc/hosts} o il DNS); tralasciamo i dettagli relativi alle varie
+direttive che possono essere usate in questi file, che si trovano nelle
 relative pagine di manuale.
 
 Con il tempo però è divenuto possibile fornire diversi sostituti per
-l'utilizzo dei file statici, ed ai nomi a dominio si sono aggiunti altri nomi,
-come quelli associati alle reti ed ai gruppi di macchine definiti dal servizio
-NIS, o quelli dei protocolli e dei servizi mantenuti nei file statici
+l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre all
+risoluzione dei nomi a dominio si sono aggiunti altri nomi da risolvere, come
+quelli associati alle reti ed ai gruppi di macchine definiti dal servizio NIS,
+o quelli dei protocolli e dei servizi mantenuti nei file statici
 \file{/etc/protocols} e \file{/etc/services}, tutte informazioni che
-normalmente non si trovano su un DNS, ma possono essere accedute in maniera
-centralizzata su opportuni server (ad esempio su LDAP) in grado di mantenerle.
+normalmente non si trovano su un DNS, ma che in un ambiente distribuito
+possono essere centralizzate su opportuni server (ad esempio su LDAP) in grado
+di mantenerle.
 
 Questo ha portato alla creazione di un sistema di risoluzione più ampio, il
 \textit{Name Service Switch} di cui il \textit{resolver} viene a costituire un
@@ -93,10 +99,10 @@ sottoinsieme. Questo sistema, che si applica anche alla risoluzioni fra nomi
 di utenti e gruppi e relativi identificatori, permette di definire in maniera
 generica (attraverso una serie di librerie dinamiche) sia i supporti su cui
 mantenere i dati di corrispondenza fra nomi e valori numerici, sia l'ordine in
-cui effettuare le ricerche sui vari supporti disponibili, ed è controllato dal
-file \file{/etc/nsswitch.conf}. Anche per questo si può fare riferimento alle
-pagine di manuale ed al relativo capitolo nel manuale \cite{glibc} delle
-\textsl{glibc}.
+cui effettuare le ricerche sui vari supporti disponibili.  Il sistema è
+controllato dal file \file{/etc/nsswitch.conf}, ed anche per questo si può
+fare riferimento alle pagine di manuale ed al relativo capitolo nel manuale
+\cite{glibc} delle \textsl{glibc}.
 
 In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
 su cui vengono mantenuti, dal punto di vista di un programma che deve
@@ -164,13 +170,14 @@ ed i valori che pu
 
 Per capire meglio il contenuto della struttura \struct{hostent} conviene
 spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un
-enorme database distribuito interrogando il quale si possono avere una serie
-di informazioni la principale delle quali è la corrispondenza fra un nome (a
-dominio) ed indirizzo IP.  Un server DNS contiene comunque una serie di altre
-informazioni; ciascuna voce nel database viene chiamata \textit{resource
-  record} e vi è associato un certo \textsl{tipo}, identificato da una sigla.
-Per quanto ci interessa i \textit{resource record} che vengono utilizzati dal
-\textit{resolver} sono sostanzialmente i seguenti:
+database distribuito organizzato in maniera gerarchica, interrogando il quale
+si possono avere una serie di informazioni la principale delle quali è la
+corrispondenza fra un nome (a dominio) ed indirizzo IP.  Un server DNS
+contiene comunque una serie di altre informazioni; ciascuna voce nel database
+viene chiamata \textit{resource record} e vi è associato un certo
+\textsl{tipo}, identificato da una sigla.  Per quanto ci interessa i tipi di
+\textit{resource record} che vengono utilizzati dal \textit{resolver} sono
+sostanzialmente i seguenti:
 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
   indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
@@ -196,13 +203,14 @@ vengono riempite le varie parti della struttura \struct{hostent}. Il primo
 campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
   canonico}, che nel caso del DNS è appunto il nome associato ad un record
 \texttt{A}. Il secondo campo della struttura invece è un puntatore ad vettore
-di puntatori, terminato da un puntatore nullo, alle strighe che contengono
-tutti i possibili altri nomi (quelli che nel DNS sarebbero record
+di puntatori, terminato da un puntatore nullo. Ciascun puntatore del vettore
+fa riferimento ad una delle stringhe che contengono tutti i possibili altri
+nomi associati allo stesso indirzzo (quelli che nel DNS sarebbero record
 \texttt{CNAME}).
 
 Il terzo campo, \var{h\_addrtype}, indica il tipo di indirizzo che è stato
 restituito, e può essere solo \const{AF\_INET} o \const{AF\_INET6}, mentre il
-quarto campo, e \var{h\_length} indica la lunghezza dell'indirizzo stesso in
+quarto campo, \var{h\_length}, indica la lunghezza dell'indirizzo stesso in
 byte. Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di
 puntatori ai singoli indirizzi; il vettore è terminato da un puntatore nullo.
 Inoltre, come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito