Aggiunto materiale vario sul resolver
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 1 Aug 2004 18:17:34 +0000 (18:17 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 1 Aug 2004 18:17:34 +0000 (18:17 +0000)
filedir.tex
fileunix.tex
img/resolver.dia
img/struct_sys.dia
listati/myhost.c [new file with mode: 0644]
process.tex
sockctrl.tex
system.tex
tcpsock.tex

index d72b71e..b9d4017 100644 (file)
@@ -1909,7 +1909,7 @@ permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
 \var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID
 effettivo e gli eventuali group-ID supplementari del processo.\footnote{in
-  realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli
+  realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
   identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
   sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
   eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa
index 950f6ff..3a0f5a5 100644 (file)
@@ -296,13 +296,13 @@ usato sempre il file descriptor con il valore pi
     asincrona (vedi sez.~\ref{sec:file_asyncronous_io}). Quando è impostato 
     viene generato il segnale \const{SIGIO} tutte le volte che sono disponibili
     dati in input sul file. \\ 
-    \const{O\_SYNC} & apre il file per l'input/output sincrono, ogni
-    \func{write} bloccherà fino al completamento della scrittura di tutti dati
-    sul sull'hardware sottostante.\\
+    \const{O\_SYNC} & apre il file per l'input/output sincrono: ogni
+    \func{write} bloccherà fino al completamento della scrittura di tutti i
+    dati sull'hardware sottostante.\\
     \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\
     \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei
-    file (vedi sez.~\ref{sec:file_file_times}). In Linux questa opzione non è
-    disponibile per il singolo file ma come opzione per il filesystem in fase
+    file (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa
+    funzionalità non è disponibile per il singolo file ma come opzione in fase
     di montaggio.\\
     \hline
   \end{tabular}
index d935609..0e596bc 100644 (file)
Binary files a/img/resolver.dia and b/img/resolver.dia differ
index cc9c1a0..64b5d95 100644 (file)
Binary files a/img/struct_sys.dia and b/img/struct_sys.dia differ
diff --git a/listati/myhost.c b/listati/myhost.c
new file mode 100644 (file)
index 0000000..0378058
--- /dev/null
@@ -0,0 +1,42 @@
+int main(int argc, char *argv[]) 
+{
+/* 
+ * Variables definition
+ */
+    int i;
+    struct hostent *data;
+    char **alias;
+    char *addr;
+    char buffer[INET6_ADDRSTRLEN];
+    ...
+    if ((argc - optind) != 1) {
+       printf("Wrong number of arguments %d\n", argc - optind);
+        usage();
+    }
+    data = gethostbyname(argv[1]);
+    if (data == NULL) {
+       herror("Errore di risoluzione");
+       exit(1);
+    }
+    printf("Canonical name %s\n", data->h_name);
+    alias = data->h_aliases;
+    while (*alias != NULL) {
+       printf("Alias %s\n", *alias);
+       alias++;
+    }
+    if (data->h_addrtype == AF_INET) {
+       printf("Address are IPv4\n");
+    } else if (data->h_addrtype == AF_INET6) {
+       printf("Address are IPv6\n");
+    } else {
+       printf("Tipo di indirizzo non valido\n");
+       exit(1);
+    }
+    alias = data->h_addr_list;
+    while (*alias != NULL) {
+       addr = inet_ntop(data->h_addrtype, *alias, buffer, sizeof(buffer));
+       printf("Indirizzo %s\n", addr);
+       alias++;
+    }    
+    exit(0);
+}
index 70dbce4..cbdbc1d 100644 (file)
@@ -1066,13 +1066,13 @@ configurazione. 
 queste variabili al programma messo in esecuzione attraverso un uso opportuno
 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
 
-La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
-la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e
-alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per
-i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
+La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH}
+per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti),
+e alcune di esse (come \texttt{HOME}, \texttt{USER}, etc.) sono definite al
+login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
 dell'amministratore definire le opportune variabili di ambiente in uno script
 di avvio. Alcune servono poi come riferimento generico per molti programmi
-(come \var{EDITOR} che indica l'editor preferito da invocare in caso di
+(come \texttt{EDITOR} che indica l'editor preferito da invocare in caso di
 necessità).
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
@@ -1089,22 +1089,22 @@ controllare \cmd{man environ}.
     & \textbf{Linux} & \textbf{Descrizione} \\
     \hline
     \hline
-    \val{USER} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\
-    \val{LOGNAME} & $\bullet$ & $\bullet$ & $\bullet$ & Nome di login\\
-    \val{HOME} & $\bullet$ & $\bullet$ & $\bullet$ & 
-    Directory base dell'utente\\
-    \val{LANG} & $\bullet$ & $\bullet$ & $\bullet$ & Localizzazione\\
-    \val{PATH} & $\bullet$ & $\bullet$ & $\bullet$ & Elenco delle directory
-                                                     dei programmi\\
-    \val{PWD} & $\bullet$ & $\bullet$ & $\bullet$ & Directory corrente\\
-    \val{SHELL} & $\bullet$ & $\bullet$ & $\bullet$ & Shell in uso\\
-    \val{TERM} & $\bullet$ & $\bullet$ & $\bullet$ & Tipo di terminale\\
-    \val{PAGER} & $\bullet$ & $\bullet$ & $\bullet$ & Programma per vedere i
-                                                      testi\\
-    \val{EDITOR} & $\bullet$ & $\bullet$ & $\bullet$ & Editor preferito\\
-    \val{BROWSER} & $\bullet$ & $\bullet$ & $\bullet$ & Browser preferito\\
-    \val{TMPDIR} & $\bullet$ & $\bullet$ & $\bullet$ & Directory dei file
-                                                       temporanei\\
+    \texttt{USER}   &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
+    \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
+    \texttt{HOME}   &$\bullet$&$\bullet$&$\bullet$& Directory base
+                                                    dell'utente\\
+    \texttt{LANG}   &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\
+    \texttt{PATH}   &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
+                                                    dei programmi\\
+    \texttt{PWD}    &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\
+    \texttt{SHELL}  &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\
+    \texttt{TERM}   &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\
+    \texttt{PAGER}  &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
+                                                    testi\\
+    \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\
+    \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\
+    \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
+                                                    temporanei\\
     \hline
   \end{tabular}
   \caption{Esempi delle variabili di ambiente più comuni definite da vari
index 62989d4..ea69815 100644 (file)
@@ -86,12 +86,13 @@ dominio, e prevedeva solo l'utilizzo del DNS e del file statico
 \file{/etc/hosts}.
 
 Per questo aspetto il file di configurazione principale del sistema è
-\file{/etc/resolv.conf} che contiene in sostanza l'elenco dei server DNS da
-contattare; a questo 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 quelli del DNS). Tralasciamo i
-dettagli relativi alle varie direttive che possono essere usate in questi
-file, che si trovano nelle rispettive pagine di manuale.
+\file{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi IP
+dei server DNS da contattare; a questo 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 quelli del DNS). Tralasciamo i dettagli relativi alle varie direttive che
+possono essere usate in questi file, che si trovano nelle rispettive pagine di
+manuale.
 
 Con il tempo però è divenuto possibile fornire diversi sostituti per
 l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre
@@ -105,11 +106,11 @@ NIS,\footnote{il \textit{Network Information Service} 
   di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
   da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
 file statici \file{/etc/protocols} e \file{/etc/services}.  Molte di queste
-informazioni non si trovano su un DNS, e poi in un ambiente distribuito può
-essere molto utile centralizzare il mentenimento di alcune di esse su
-opportuni server. Inoltre l'uso di diversi supporti possibili per le stesse
-informazioni (ad esempio il nome delle macchine può essere mantenuto sia
-tramite \file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema
+informazioni non si trovano su un DNS, ma in una rete locale può essere molto
+utile centralizzare il mentenimento di alcune di esse su opportuni server.
+Inoltre l'uso di diversi supporti possibili per le stesse informazioni (ad
+esempio il nome delle macchine può essere mantenuto sia tramite
+\file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema
 dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni
   classiche i vari supporti erano introdotti modificando direttamente le
   funzioni di liberia, prevedendo un ordine di interrogazione predefinito e
@@ -206,38 +207,43 @@ server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
 generiche di libreria usate anche dal sistema del \textit{resolver}.
 
 Il sistema del DNS è in sostanza di un database distribuito organizzato in
-maniera gerarchica, la manutenzione dei dati è mantenuta in tanti server
-distinti ciascuno dei quali si occupa della risoluzione del proprio
-\textsl{dominio}; i nomi a dominio sono poi organizzati in una struttura ad
-albero analoga a quella dell'albero dei file in un sistema unix-like, con
-domini di primo livello (come i \texttt{.org}), secondo livello (come
-\texttt{.truelite.it}), ecc.  In questo caso le separazioni sono fra i vari
-livelli sono definite dal carattere ``\texttt{.}''  ed i nomi devono essere
-risolti da destra verso sinistra. Il meccanismo funziona con il criterio della
-\textsl{delegazione}, un server responsabile per un dominio di primo livello
-può delegare la risoluzione degli indirizzi per un suo dominio di secondo
-livello ad un altro server, il quale a sua volta potrà delegare la risoluzione
-di un eventuale sottodominio di terzo livello ad un altro server ancora.
-
-In realtà un server DNS contiene comunque una serie di altre informazioni;
-ciascuna voce nel database viene chiamata \textit{resource record}, e può
-contenere diverse informazioni; in genere i \textit{resource record} vengono
-classificati per la \textsl{classe di indirizzi} cui i dati contenuti fanno
-riferimento, e per il \textsl{tipo} di questi ultimi. Oggigiorno i dati
-mantenuti nei server DNS sono sostanzialmente relativi soltanto ad indirizzi
-internet, per cui in pratica c'è soltanto una classe di indirizzi utilizzata,
-i dati invece possono essere di vario tipo, uno dei quali è appunto la
-corrispondenza fra nome a dominio e numero IP.
-
-L'esistenza di vari tipi di informazioni ottenibili da un server DNS è
-un'altro dei motivi per cui il \textit{resolver} prevede un insieme di
-funzioni dedicato rispetto a quelle della semplice risoluzione dei nomi; la
-prima di queste è \funcd{res\_init}, il cui prototipo è:
+maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno
+dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a
+dominio sono organizzati in una struttura ad albero analoga a quella
+dell'albero dei file, con domini di primo livello (come i \texttt{.org}),
+secondo livello (come \texttt{.truelite.it}), ecc.  In questo caso le
+separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}''
+ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si
+  stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
+  ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
+  genere non viene mai scritto esplicitamente, ma che, come chiunque abbia
+  configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
+  \textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo
+funziona con il criterio della \textsl{delegazione}, un server responsabile
+per un dominio di primo livello può delegare la risoluzione degli indirizzi
+per un suo dominio di secondo livello ad un altro server, il quale a sua volta
+potrà delegare la risoluzione di un eventuale sottodominio di terzo livello ad
+un altro server ancora.
+
+In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
+un nome a dominio in un indirizzo IP; ciascuna voce nel database viene
+chiamata \textit{resource record}, e può contenere diverse informazioni; in
+genere i \textit{resource record} vengono classificati per la \textsl{classe
+  di indirizzi} cui i dati contenuti fanno riferimento, e per il \textsl{tipo}
+di questi ultimi. Oggigiorno i dati mantenuti nei server DNS sono
+sostanzialmente relativi soltanto ad indirizzi internet, per cui in pratica
+c'è soltanto una classe di indirizzi utilizzata, i dati invece possono essere
+di vario tipo, uno dei quali è appunto la corrispondenza fra nome a dominio e
+numero IP.
+
+L'esistenza di vari tipi di informazioni è un'altro dei motivi per cui il
+\textit{resolver} prevede, rispetto a quelle relative alla semplice
+risoluzione dei nomi, un insieme di funzioni specifiche dedicate
+all'interrogazione di un server DNS; la prima di queste funzioni è
+\funcd{res\_init}, il cui prototipo è:
 \begin{functions}
-\headdecl{netinet/in.h}
-\headdecl{arpa/nameser.h}
-\headdecl{resolv.h}
-\funcdecl{int res\_init(void)}
+  \headdecl{netinet/in.h} \headdecl{arpa/nameser.h} \headdecl{resolv.h}
+  \funcdecl{int res\_init(void)}
 
 Inizializza il sistema del \textit{resolver}.
 
@@ -245,29 +251,28 @@ Inizializza il sistema del \textit{resolver}.
   errore.}
 \end{functions}
 
-La funzione legge il contenuto dei file di configurazione per impostare il
-dominio di default, gli indirizzi dei server DNS da contattare e l'ordine
-delle ricerche; se non sono specificati server verrà utilizzato l'indirizzo
-locale, e se non è definito un dominio di default sarà usato quello associato
-con l'indirizzo locale. In genere si deve eseguire questa funzione prima di
-chiamare tutte le altre. 
+La funzione legge il contenuto dei file di configurazione (i già citati
+\file{resolv.conf} e \file{host.conf}) per impostare il dominio di default,
+gli indirizzi dei server DNS da contattare e l'ordine delle ricerche; se non
+sono specificati server verrà utilizzato l'indirizzo locale, e se non è
+definito un dominio di default sarà usato quello associato con l'indirizzo
+locale (ma questo può essere sovrascritto con l'uso della variabile di
+ambiente \texttt{LOCALDOMAIN}). In genere è necessario eseguire questa
+funzione direttamente in quanto viene automaticamente chiamata la prima che si
+esegue una delle altre.
 
 Le impostazioni del resolver e lo stato del sistema vengono mantenute in una
-serie di variabili globali contenuti in una apposita struttura interna,
-definita in \file{resolv.h}, che può essere acceduta una volta che la si
-dichiara con:
-\includecodesnip{listati/resolv_option.c}
-
-Tutti i campi della struttura sono ad uso interno, l'unico che può essere
-utile modificare è il campo \var{\_res.options}, che è una maschera binaria
-che permette di controllare il comportamento del resolver, modificandone
-alcune impostazioni direttamente da programma prima di invocare
-\func{res\_init}. Le costanti che definiscono i vari bit di questo campo, con
-il relativo significato sono illustrate in tab.~\ref{tab:resolver_option}, un
-valore deve essere espresso con un opportuno OR aritmetico di dette costanti;
-ad esempio il valore di default dato dalla costante \const{RES\_DEFAULT} è 
-definito come: 
-\includecodesnip{listati/resolv_option_def.c}
+serie di variabili contenute in una apposita struttura interna che viene
+definita in \file{resolv.h} ed è utilizzata come variabile globale, così che
+anche un programma vi può accedure una volta che essa sia stata opportunamente
+dichiarata come: \includecodesnip{listati/resolv_option.c}
+
+Tutti i campi della struttura sono ad uso interno, e vengono usualmente
+inizializzati da \func{res\_init} in base al contenuto dei file di
+configurazione e ad una serie di valori di default. L'unico campo che può
+essere utile modificare è \var{\_res.options}, una maschera binaria che
+contiene una serie di bit di opzione che permettono di controllare il
+comportamento del resolver. 
 
 \begin{table}[htb]
   \centering
@@ -318,10 +323,37 @@ definito come:
   \label{tab:resolver_option}
 \end{table}
 
-La funzione di richiesta principale è \funcd{res\_query}, che serve ad
-eseguire una richiesta ad un server DNS per un nome a dominio completamente
-specificato (quello che si chiama FQDN, \textit{Fully Qualified Domain Name});
-il suo prototipo è:
+Per utilizzare questa funzionalità per modificare le impostazioni direttamente
+da programma occorrerà impostare un opportuno valore per questo campo ed
+invocare esplicitamente \func{res\_init}, dopo di che le altre funzioni
+prenderanno le nuove impostazioni. Le costanti che definiscono i vari bit di
+questo campo, ed il relativo significato sono illustrate in
+tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
+deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
+esempio il valore di default delle opzioni, epsresso dalla costante
+\const{RES\_DEFAULT}, è definito come:
+\includecodesnip{listati/resolv_option_def.c}
+
+Non tratteremo il significato degli altri campi non essendovi necessità di
+modificarli direttamente; gran parte di essi sono infatti impostati dal
+contenuto dei file di configurazione, mentre le funzionalità controllate da
+alcuni di esse possono essere modificate con l'uso delle opportune variabili
+di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
+\texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
+controlla quante volte viene ripetuto il tentativo di connettersi ad un server
+DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
+significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
+soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
+  della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
+valore preso come base (in numero di secondi) per definire la scadenza di una
+richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppianto
+il tempo di scadenza per il numero massimo di volte stabilito da
+\texttt{RES\_RETRY}.
+
+La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
+eseguire una richiesta ad un server DNS per un nome a dominio
+\textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
+  Qualified Domain Name}); il suo prototipo è:
 
 \begin{functions}
 \headdecl{netinet/in.h}
@@ -332,53 +364,250 @@ il suo prototipo 
 
   Esegue una interrogazione al DNS.
 
-\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-  errore.}
+\bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei
+    dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di
+    errore.}
 \end{functions}
 
+La funzione esegue una interrogazione ad un server DNS relativa al nome da
+risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve
+essere specificata la classe di indirizzi in cui eseguire la ricerca con
+\param{class}, ed il tipo di \textit{resource record} che si vuole ottenere
+con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
+lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
+allocato in precedenza.
+
 
-Per quanto ci interessa i tipi di \textit{resource record} che vengono
-utilizzati dal \textit{resolver} sono sostanzialmente i seguenti:
+Una seconda funzione di ricerca, analoga a \func{res\_query}, e che prende gli
+stessi argomenti, ma esegue l'interrogazione con le funzionalità addizionali
+previste dalle due opzioni \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}, è
+\funcd{res\_search}, il cui prototipo è:
+\begin{functions}
+\headdecl{netinet/in.h}
+\headdecl{arpa/nameser.h}
+\headdecl{resolv.h}
+\funcdecl{int res\_search(const char *dname, int class, int type,
+              unsigned char *answer, int anslen)}
+
+  Esegue una interrogazione al DNS.
+  
+  \bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei
+    dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di
+    errore.}
+\end{functions}
+
+In sostanza la funzione ripete una serie di chiamate a \func{res\_query}
+aggiungendo opportunamente il dominio di default da cercare nella stinga
+\param{dname}, fermandosi non appena trova un risultato.  Il risultato di
+entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
+seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
+programma (o di altre funzioni) estrarre i relativi dati, esistono una serie
+di funzioni interne usate per la scansione di questi dati, per chi fosse
+interessato una trattazione dettagliata è riportata nel capitolo 14 di
+\cite{DNSbind}.
+
+Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in
+pratica oggi viene utilizzata solo quella degli indirizzi internet; le
+costanti che identificano dette classi come valore per l'argomento
+\param{class} sono riportate in
+tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
+  \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|p{8cm}|}
+    \hline
+    \textbf{Costante} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{C\_IN}   & indirizzi internet, in pratica i soli utilizzati oggi.\\
+    \const{C\_HS}   & indirizzi \textit{Hesiod}, utilizzati solo al MIT, oggi
+                      completamente estinti. \\
+    \const{C\_CHAOS}& indizzi per la rete \textit{Chaosnet}, un'altra rete
+                      sperimentale nata al MIT. \\
+    \const{C\_ANY}  & indica un indirizzo di classe qualunque.\\
+    \hline
+  \end{tabular}
+  \caption{Costanti identificative delle classi di indirizzi per l'argomento
+    \param{class} di \func{res\_query}.}
+  \label{tab:DNS_address_class}
+\end{table}
+
+Come accennato le tipologie di dati che sono mantenibili su un DNS sono
+diverse, ed a ciascuna di essa corriponde ad un diverso tipo di
+\textit{resource record}; l'elenco dei valori possibili\footnote{come
+  ottenibile dai file di dichiarazione \file{arpa/nameser.h} e
+  \file{arpa/nameser_compat.h}.} che si possono indicare per l'argomento
+\param{type} è riportato in tab.~\ref{tab:DNS_record_type}; le costanti (tolto
+il \texttt{T\_} iniziale) usano gli stessi valori usati per identificare i
+record nei file di zona di BIND, e che normalmente sono anche usati come
+\textsl{nomi} per indicare i record.
+
+\begin{table}[!htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Costante} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{T\_A}     & indirizzo di una stazione.\\
+    \const{T\_NS}    & server DNS autoritativo per il dominio richiesto.\\
+    \const{T\_MD}    & destinazione per la posta elettronica.\\
+    \const{T\_MF}    & redistributore per la posta elettronica.\\
+    \const{T\_CNAME} & nome canonico.\\
+    \const{T\_SOA}   & inzio di una zona di autorità.\\
+    \const{T\_MB}    & nome a dominio di una casella di posta.\\
+    \const{T\_MG}    & nome di un membro di un gruppo di posta.\\
+    \const{T\_MR}    & nome di un cambiamento di nome per la posta.\\
+    \const{T\_NULL}  & record nullo.\\
+    \const{T\_WKS}   & servizio noto.\\
+    \const{T\_PTR}   & risoluzione inversa di un indirizzo numerico.\\
+    \const{T\_HINFO} & informazione sulla stazione.\\
+    \const{T\_MINFO} & informazione sulla casella di posta.\\
+    \const{T\_MX}    & server cui instradare la posta per il dominio.\\
+    \const{T\_TXT}   & stringhe di testo (libere).\\
+    \const{T\_RP}    & nome di un responsabile (\textit{responsible person}).\\
+    \const{T\_AFSDB} & database per una cella AFS.\\
+    \const{T\_X25}   & indirizzo di chiamata per X.25.\\
+    \const{T\_ISDN}  & indirizzo di chiamata per ISDN.\\
+    \const{T\_RT}    & router.\\
+    \const{T\_NSAP}  & indirizzo NSAP.\\
+    \const{T\_NSAP\_PTR}& risoluzione inversa per NSAP (deprecato).\\
+    \const{T\_SIG}   & firma digitale di sicurezza.\\
+    \const{T\_KEY}   & chiave per firma.\\
+    \const{T\_PX}    & corrispondenza per la posta X.400.\\
+    \const{T\_GPOS}  & posizione grografica.\\
+    \const{T\_AAAA}  & indirizzo IPv6.\\
+    \const{T\_LOC}   & informazione di collocazione.\\
+    \const{T\_NXT}   & dominio successivo.\\
+    \const{T\_EID}   & identificatore di punto conclusivo.\\
+    \const{T\_NIMLOC}& posizionatore \textit{nimrod}.\\
+    \const{T\_SRV}   & servizio.\\
+    \const{T\_ATMA}  & indirizzo ATM.\\
+    \const{T\_NAPTR} & puntatore ad una \textit{naming authority} .\\
+    \const{T\_TSIG}  & firma di transazione.\\
+    \const{T\_IXFR}  & trasferimento di zona incrementale.\\
+    \const{T\_AXFR}  & trasferimenzo di zona di autorità.\\
+    \const{T\_MAILB} & trasferimento di record di caselle di posta.\\
+    \const{T\_MAILA} & trasferimetno di record di server di posta.\\
+    \const{T\_ANY}   & valore generico.\\
+    \hline
+  \end{tabular}
+  \caption{Costanti identificative del tipo di record per l'argomento
+    \param{type} di \func{res\_query}.}
+  \label{tab:DNS_record_type}
+\end{table}
+
+
+L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
+\textit{resource record} definiti, con una breve descrizione del relativo
+significato.  Di tutti questi però viene impiegato correntemente solo un
+piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati
+applicativi che non ci interessano, pertanto non entreremo nei dettagli del
+significato di tutti quanti, ma solo di quelli usati dalle funzioni del
+\textit{resolver}, che sono sostanzialmente i seguenti:
 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
+\item[\texttt{A}] per indicare la corripondenza fra un nome a dominio ed un
   indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
   e l'indirizzo IP \texttt{62.48.34.25}.
-\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro
-  volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
-  fra un nome a dominio ed un indirizzo IPv6.
+\item[\texttt{AAAA}] per indicare la corrispondenza fra un nome a dominio ed
+  un indirizzo IPv6; è chiamato in questo modo dato che la dimensione di un
+  indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
 \item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
-  un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
-  per \textit{pointer}).
-\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
-  indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
-  \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
-  macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per
-  creare degli \textit{alias} in modo da associare un qualunque altro nome al
+  un nome a dominio si utilizza questo tipo di record (il cui nome sta per
+  \textit{pointer}).
+\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
+  stesso indirizzo (come ad esempio \texttt{www.truelite.it}, o
+  \texttt{sources.truelite.it}, che fanno sempre riferimento a
+  \texttt{dodds.truelite.it}) si può usare questo tipo di record per creare
+  degli \textit{alias} in modo da associare un qualunque altro nome al
   \textsl{nome canonico} della macchina (quello associato al record
   \texttt{A}).
 \end{basedescript}
 
+Come accennato in caso di successo le due funzioni di richiesta restituiscono
+il risultato della interrogazione al server, in caso di insuccesso l'errore
+invece viene segnalato da un valore di ritorno pari a -1, ma in questo caso, a
+differenza delle funzioni viste finora, non può essere utilizzata la variabile
+\var{errno} per riportare un codice di errore, in quanto questo viene
+impostato per ciascuna delle chiamate al sistema utilizzate, e può non avere
+nessun significato nell'indicare quale parte del procedimento di risoluzione è
+fallita.
 
+Per questo motivo all'interno del resolver è stata definita una apposita
+variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni del
+resolver per indicare quale problema ha causato il fallimento della
+risoluzione del nome. Ad essa si può accedere una volta che la si dichiara
+con: 
+\includecodesnip{listati/herrno.c} 
+ed i valori che può assumere sono riportati in tab.~\ref{tab:h_errno_values}.
+
+
+\begin{table}[!htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|p{10cm}|}
+    \hline
+    \textbf{Costante} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{HOST\_NOT\_FOUND} & l'indirizzo richiesto non è valido e la
+                               macchina indicata è sconosciuta. \\
+    \const{NO\_ADDRESS}      & il nome a dominio richiesto è valido, ma non ha
+                               un indirizzo associato ad esso
+                               (alternativamente può essere indicato come 
+                               \const{NO\_DATA}). \\
+    \const{NO\_RECOVERY}     & si è avuto un errore non recuperabile
+                               nell'interrogazione di un server DNS. \\
+    \const{TRY\_AGAIN}       & si è avuto un errore temporaneo
+                               nell'interrogazione di un server DNS, si può
+                               ritentare l'interrogazione in un secondo
+                               tempo. \\
+    \hline
+  \end{tabular}
+  \caption{Valori possibili della variabile \var{h\_errno}.}
+  \label{tab:h_errno_values}
+\end{table}
 
 
+Insieme alla nuova variabile vengono definite anche due nuove funzioni per
+stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror},
+ma che usano il valore di \var{h\_errno}; la prima è \funcd{herror} ed il suo
+prototipo è:
+\begin{functions}
+\headdecl{netdb.h}
+\funcdecl{void herror(const char *string)}
 
+Stampa un errore di risoluzione.
+\end{functions}
+
+La funzione è l'analoga di \func{perror} e stampa sullo standard error un
+messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui
+viene anteposta la stringa \param{string} passata come argomento.  La seconda
+funzione è \funcd{hstrerror} ed il suo prototipo è:
+\begin{functions}
+\headdecl{netdb.h}
+\funcdecl{const char *hstrerror(int err)}
+
+Restituisce una stringa corripondente ad un errore di risoluzione.
+\end{functions}
+\noindent e come per l'analoga \func{strerror} restituise una stringa con un
+messaggio di errore già formattato corrispondente al codice passato come
+argomento (che si presume sia dato da \var{h\_errno}).
 
-Per questo motivo il \textit{resolver} prevede delle funzioni che permettono
-sia di eseguire direttamente delle interrogazione ad un server DNS, che di
-controllare le modalità con cui queste vengono eseguite; diventa così
-possibile modificare da programma buona parte dei parametri controllati da
-\file{/etc/resolv.conf}.
 
 
 
 \subsection{La risoluzione dei nomi a dominio}
 \label{sec:sock_gethostbyname}
 
-Dato che la principale funzionalità del \textit{resolver} resta quella di
-risolvere i nomi a dominio in indirizzi IP, vedremo per prime le funzioni a
-questo dedicate. La prima funzione è \funcd{gethostbyname} il cui scopo è
-ottenere l'indirizzo di una stazione noto il suo nome a dominio, il suo
-prototipo è:
+La principale funzionalità del \textit{resolver} resta quella di risolvere i
+nomi a dominio in indirizzi IP, per cui non ci dedicheremo oltre alle funzioni
+di richiesta generica ed esamineremo invece le funzioni a questo dedicate. La
+prima funzione è \funcd{gethostbyname} il cui scopo è ottenere l'indirizzo di
+una stazione noto il suo nome a dominio, il suo prototipo è:
 \begin{prototype}{netdb.h}
 {struct hostent *gethostbyname(const char *name)}
 
@@ -392,13 +621,7 @@ Determina l'indirizzo associato al nome a dominio \param{name}.
 La funzione prende come argomento una stringa \param{name} contenente il nome
 a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
 vengono memorizzati in una opportuna struttura \struct{hostent} la cui
-definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. In caso di
-insuccesso l'errore viene segnalato da un valore nullo del puntatore, ma in
-questo caso, a differenza delle funzioni viste finora, non viene utilizzata la
-variabile \var{errno} per riportare un codice di errore, in quanto questo
-dipende solo dalle sottostanti chiamate al sistema e può non avere nessun
-significato nell'indicare quale parte del procedimento di risoluzione è
-fallita.
+definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. 
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -409,29 +632,10 @@ fallita.
   \label{fig:sock_hostent_struct}
 \end{figure}
 
-Per questo motivo all'interno del resolver è stata definita una apposita
-variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni di
-libreria per indicare quale problema ha causato il fallimento della
-risoluzione del nome. Ad essa si può accedere una volta che la si dichiara
-con: 
-\includecodesnip{listati/herrno.c} 
-ed i valori che può assumere sono i seguenti:
-\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{HOST\_NOT\_FOUND}] l'indirizzo richiesto non è valido e la
-  macchina indicata è sconosciuta.
-\item[\const{NO\_ADDRESS}] il nome a dominio richiesto è valido, ma non ha un
-  indirizzo associato ad esso (alternativamente può essere indicato come
-  \const{NO\_DATA}).
-\item[\const{NO\_RECOVERY}] si è avuto un errore non recuperabile
-  nell'interrogazione di un server DNS.
-\item[\const{TRY\_AGAIN}] si è avuto un errore temporaneo nell'interrogazione
-  di un server DNS, si può ritentare l'interrogazione in un secondo tempo. 
-\end{basedescript}
-
 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
-effettuare la risoluzione del nome, è con i valori di questi record che
-vengono riempite le varie parti della struttura \struct{hostent}. Il primo
-campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
+effettuare la risoluzione del nome, è con i valori contenuti nei relativi
+record che 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, \var{h\_aliases}, invece è un
 puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
@@ -442,8 +646,7 @@ DNS vengono inseriti come record di tipo \texttt{CNAME}).
 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
 che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
-lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una
-struttura 
+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,
@@ -460,8 +663,46 @@ corrispondente struttura \var{in\_addr} da indirizzara con
 \code{h\_addr\_list[0]}.
 
 
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includecodesample{listati/myhost.c}
+  \end{minipage}
+  \normalsize
+  \caption{Esempio di codice per la risoluzione di un indirizzo.}
+  \label{fig:myhost_example}
+\end{figure}
+
+Vediamo allora un primo esempio dell'uso di queste funzioni, in
+fig.~\ref{fig:myhost_example} è riportato un estratto del codice di un
+programma che esegue una semplice interrogazione al resolver usando
+\func{gethostbyname} e stampa a video i risultati. Al solito il sorgente
+completo, he comprende il trattamento delle opzioni ed una funzione per
+stampare un messaggio di aiuto, è nel file \texttt{myhost.c} dei sorgenti
+allegati alla guida.
+
+
+
+Con l'uso di \func{gethostbyname} normalmente si ottengono solo gli indirizzi
+IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
+l'opzione \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e chiamare
+\func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per modificare
+le opzioni del resolver; dato che questo non è molto comodo è stata definita
+un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è:
+\begin{prototype}{netdb.h}
+{struct hostent *gethostbyname2(const char *name, int af)}
+
+Determina l'indirizzo di tipo \param{af} associato al nome a dominio
+\param{name}.
+
+\bodydesc{La funzione restituisce in caso di successo il puntatore ad una
+  struttura di tipo \struct{hostent} contente i dati associati al nome a
+  dominio o un puntatore nullo in caso di errore.}
+\end{prototype}
 
 
+In questo caso la funzione prende un secondo argomento \param{af} che indica
+la famiglia di indirizzi da usare come 
 
 
 
index 3c06330..8359d3f 100644 (file)
@@ -1207,7 +1207,7 @@ e \funcd{pututline}, i cui prototipi sono:
   \headdecl{utmp.h} 
 
   \funcdecl{struct utmp *getutent(void)} 
-  Legge una voce dal dalla posizione corrente nel registro.
+  Legge una voce dalla posizione corrente nel registro.
   
   \funcdecl{struct utmp *getutid(struct utmp *ut)} Ricerca una voce sul
   registro in base al contenuto di \param{ut}.
index 7dcdaf1..bc65ae9 100644 (file)
@@ -1302,7 +1302,7 @@ arrivati alla fine del file (per i socket questo significa in genere che
 l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
 pertanto si ritorna senza aver concluso la lettura di tutti i byte
 richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
-valore negativo in caso di errore, \texttt{FullRead} restituisce il numero di
+valore negativo in caso di errore, \func{FullRead} restituisce il numero di
 byte non letti in caso di end-of-file prematuro.
 
 
@@ -1316,9 +1316,9 @@ nell'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}, che restituisce
 l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
 alla porta 13.
 
-In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale del
-codice del nostro client. Il sorgente completo del programma
-(\file{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
+In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
+del codice del nostro client. Il sorgente completo del programma
+(\texttt{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
 funzione per stampare un messaggio di aiuto) è allegato alla guida nella
 sezione dei codici sorgente e può essere compilato su una qualunque macchina
 GNU/Linux.
@@ -1418,7 +1418,8 @@ elementare, che sia anche in grado di rispondere al precedente client. Come
 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
 risposta alla volta. Il codice del programma è nuovamente mostrato in
 fig.~\ref{fig:TCP_daytime_iter_server_code}, il sorgente completo
-(\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi.
+(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
+esempi.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
@@ -1515,8 +1516,8 @@ In fig.~\ref{fig:TCP_daytime_cunc_server_code} 
 codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
 rimaste invariate rispetto al precedente esempio (cioè tutta la parte
 riguardante l'apertura passiva del socket). Al solito il sorgente completo del
-server, nel file \file{TCP\_cunc\_daytimed.c}, è allegato insieme ai sorgenti
-degli altri esempi.
+server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
+sorgenti degli altri esempi.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1652,11 +1653,11 @@ output.
 \label{sec:TCP_echo_client}
 
 Il codice della prima versione del client per il servizio \textit{echo},
-disponibile nel file \file{TCP\_echo\_first.c}, è riportato in
+disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
 fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
 client per il servizio \textit{daytime} (vedi
-sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) è
-sostanzialmente identica, a parte l'uso di una porta diversa.
+sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
+è sostanzialmente identica, a parte l'uso di una porta diversa.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1733,11 +1734,11 @@ illustriamo immediatamente.
 \subsection{Il server \textit{echo}: prima versione}
 \label{sec:TCPsimp_server_main}
 
-La prima versione del server, contenuta nel file \file{TCP\_echod\_first.c}, è
-riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto per
-il client anche il server è stato diviso in un corpo principale, costituito
-dalla funzione \code{main}, che è molto simile a quello visto nel precedente
-esempio per il server del servizio \textit{daytime} di
+La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
+è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
+per il client anche il server è stato diviso in un corpo principale,
+costituito dalla funzione \code{main}, che è molto simile a quello visto nel
+precedente esempio per il server del servizio \textit{daytime} di
 sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
 \code{ServEcho} che si cura della gestione del servizio.
 
@@ -2097,8 +2098,8 @@ riscrittura parziale del server, la nuova versione di questo, in cui si sono
 introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
 mostrata in fig.~\ref{fig:TCP_echo_server_code_second}, dove si sono riportate
 la sezioni di codice modificate nella seconda versione del programma, il
-codice completo di quest'ultimo si trova nel file \file{TCP\_echod\_second.c}
-dei sorgenti allegati alla guida.
+codice completo di quest'ultimo si trova nel file
+\texttt{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
 
 La prima modifica effettuata è stata quella di introdurre una nuova opzione a
 riga di comando, \texttt{-c}, che permette di richiedere il comportamento
@@ -3141,11 +3142,11 @@ tutti i dati e della terminazione effettiva della connessione.
   \label{fig:TCP_ClientEcho}
 \end{figure}
 
-Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale della
-nostra funzione \func{ClientEcho}, in grado di gestire correttamente l'intero
-flusso di dati fra client e server. Il codice completo del client,
+Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
+della nostra funzione \func{ClientEcho}, in grado di gestire correttamente
+l'intero flusso di dati fra client e server. Il codice completo del client,
 comprendente la gestione delle opzioni a riga di comando e le istruzioni per
-la creazione della connessione, si trova nel file \file{TCP\_echo.c},
+la creazione della connessione, si trova nel file \texttt{TCP\_echo.c},
 distribuito coi sorgenti allegati alla guida.
 
 La nuova versione è molto simile alla precedente di
@@ -3437,10 +3438,11 @@ ma la struttura del programma resta sostanzialmente la stessa.
 
 In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
 versione del server, la versione completa del codice è riportata nel file
-\file{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella figura
-si sono tralasciate la gestione delle opzioni, la creazione del socket in
-ascolto, la cessione dei privilegi e le operazioni necessarie a far funzionare
-il programma come demone, privilegiando la sezione principale del programma.
+\texttt{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella
+figura si sono tralasciate la gestione delle opzioni, la creazione del socket
+in ascolto, la cessione dei privilegi e le operazioni necessarie a far
+funzionare il programma come demone, privilegiando la sezione principale del
+programma.
 
 Come per il precedente server basato su \func{select} il primo passo
 (\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato