Modifiche al sito
[gapil.git] / sockctrl.tex
1 %% sockctrl.tex
2 %%
3 %% Copyright (C) 2004 Simone Piccardi.  Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
9 %% License".
10 %%
11 \chapter{La gestione dei socket}
12 \label{cha:sock_generic_management}
13
14 Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
15 alla gestione dei socket, come la gestione della risoluzione di nomi e
16 indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
17 socket, e le funzioni di controllo che permettono di modificarne il
18 comportamento.
19
20
21 \section{La risoluzione dei nomi}
22 \label{sec:sock_name_resolution}
23
24 Negli esempi dei capitoli precedenti abbiamo sempre identificato le singole
25 macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
26 conversione elementare illustrate in sez.~\ref{sec:sock_addr_func} che
27 permettono di passare da un indirizzo espresso in forma dotted decimal ad un
28 numero. Vedremo in questa sezione le funzioni utilizzate per poter utilizzare
29 dei nomi simbolici al posto dei valori numerici, e viceversa quelle che
30 permettono di ottenere i nomi simbolici associati ad indirizzi, porte o altre
31 proprietà del sistema.
32
33
34 \subsection{La struttura del \textit{resolver}}
35 \label{sec:sock_resolver}
36
37 La risoluzione dei nomi è associata tradizionalmente al servizio del
38 \textit{Domain Name Service} che permette di identificare le macchine su
39 internet invece che per numero IP attraverso il relativo \textsl{nome a
40   dominio}.\footnote{non staremo ad entrare nei dettagli della definizione di
41   cosa è un nome a dominio, dandolo per noto, una introduzione alla
42   problematica si trova in \cite{AGL} (cap. 9) mentre per una trattazione
43   approfondita di tutte le problematiche relative al DNS si può fare
44   riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
45 server che forniscono su internet questo servizio, mentre nel nostro caso
46 affronteremo la problematica dal lato client, di un qualunque programma che
47 necessita di compiere questa operazione.
48
49 \begin{figure}[htb]
50   \centering
51   \includegraphics[width=10cm]{img/resolver}
52   \caption{Schema di funzionamento delle routine del \textit{resolver}.}
53   \label{fig:sock_resolver_schema}
54 \end{figure}
55
56 Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza
57 possibile fra nomi simbolici e valori numerici, come abbiamo visto anche in
58 sez.~\ref{sec:sys_user_group} per le corrispondenze fra nomi di utenti e
59 gruppi e relativi identificatori numerici; per quanto riguarda però tutti i
60 nomi associati a identificativi o servizi relativi alla rete il servizio di
61 risoluzione è gestito in maniera unificata da un insieme di routine fornite
62 con le librerie del C, detto appunto \textit{resolver}.
63
64 Lo schema di funzionamento del \textit{resolver} è illustrato in
65 fig.~\ref{fig:sock_resolver_schema}; in sostanza i programmi hanno a
66 disposizione un insieme di funzioni di libreria con cui chiamano il
67 \textit{resolver}, indicate con le freccie nere. Ricevuta la richiesta è
68 quest'ultimo che, sulla base della sua configurazione, esegue le operazioni
69 necessarie a fornire la risposta, che possono essere la lettura delle
70 informazioni mantenute nei relativi dei file statici presenti sulla macchina,
71 una interrogazione ad un DNS (che a sua volta, per il funzionamento del
72 protocollo può interrogarene altri) o la richiesta ad altri server per i quali
73 sia fornito il supporto, come LDAP.\footnote{la sigla LDAP fa riferimento ad
74   un protocollo, il \textit{Lightweight Directory Access Protocol}, che
75   prevede un meccanismo per la gestione di \textsl{elenchi} di informazioni
76   via rete; il contenuto di un elenco può essere assolutamente generico, e
77   questo permette il manenimento dei più vari tipi di informazioni su una
78   infrastruttura di questo tipo.}
79
80 La configurazione del \textit{resolver} attiene più alla amministrazione di
81 sistema che alla programmazione, ciò non di meno, prima di trattare le varie
82 funzioni di librerie utilizzate dai programmi, vale la pena fare una
83 panoramica generale.  Originariamente la configurazione del \textit{resolver}
84 riguardava esclusivamente le questioni relative alla gestione dei nomi a
85 dominio, e prevedeva solo l'utilizzo del DNS e del file statico
86 \file{/etc/hosts}.
87
88 Per questo aspetto il file di configurazione principale del sistema è
89 \file{/etc/resolv.conf} che contiene in sostanza l'elenco dei server DNS da
90 contattare; a questo si affianca il file \file{/etc/host.conf} il cui scopo
91 principale è indicare l'ordine in cui eseguire la risoluzione dei nomi (se
92 usare prima i valori di \file{/etc/hosts} o quelli del DNS). Tralasciamo i
93 dettagli relativi alle varie direttive che possono essere usate in questi
94 file, che si trovano nelle rispettive pagine di manuale.
95
96 Con il tempo però è divenuto possibile fornire diversi sostituti per
97 l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre
98 alla risoluzione dei nomi a dominio ci sono anche altri nomi da risolvere,
99 come quelli che possono essere associati ad una rete (invece che ad una
100 singola macchina) o ai gruppi di macchine definiti dal servizio
101 NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
102   Sun, e poi diffuso su tutte le piattaforme unix-like, che permette di
103   raggruppare all'interno di una rete (in quelli che appunto vengono chiamati
104   \textit{netgroup}) varie macchine, centralizzando i servizi di definizione
105   di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
106   da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
107 file statici \file{/etc/protocols} e \file{/etc/services}.  Molte di queste
108 informazioni non si trovano su un DNS, e poi in un ambiente distribuito può
109 essere molto utile centralizzare il mentenimento di alcune di esse su
110 opportuni server. Inoltre l'uso di diversi supporti possibili per le stesse
111 informazioni (ad esempio il nome delle macchine può essere mantenuto sia
112 tramite \file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema
113 dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni
114   classiche i vari supporti erano introdotti modificando direttamente le
115   funzioni di liberia, prevedendo un ordine di interrogazione predefinito e
116   non modificabile (a meno di una ricompilazione delle librerie stesse).}
117
118 Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
119 eseguira dal \textit{resolver} è stata inclusa all'interno di un meccanismo
120 generico per la risoluzione di corripondenze fra nomi ed informazioni ad essi
121 associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
122   introdotto la prima volta nelle librerie standard di Solaris, le \acr{glibc}
123   hanno ripreso lo stesso schema, si tenga presente che questo sistema non
124   esiste per altre librerie standard come le \acr{libc5} o le \acr{uclib}.}
125 cui abbiamo accennato anche in sez.~\ref{sec:sys_user_group} per quanto
126 riguarda la gestione dei dati associati a utenti e gruppi.  Il \textit{Name
127   Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
128 sistema di librerie dinamiche che permette di definire in maniera generica sia
129 i supporti su cui mantenere i dati di corrispondenza fra nomi e valori
130 numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti
131 disponibili. Il sistema prevede una serie di possibili classi di
132 corrispondenza, quelle attualmente definite sono riportate in
133 tab.~\ref{tab:sys_NSS_classes}.
134
135 \begin{table}[htb]
136   \footnotesize
137   \centering
138   \begin{tabular}[c]{|l|p{8cm}|}
139     \hline
140     \textbf{Classe} & \textbf{Tipo di corrispondenza}\\
141     \hline
142     \hline
143     \texttt{shadow}   & corrispondenze fra username e proprietà dell'utente
144                        (\acr{uid}, ecc.).\\  
145     \texttt{group}    & corrispondenze fra nome del gruppo e proprietà dello 
146                         stesso.\\  
147     \texttt{aliases}  & alias per la posta elettronica\\ 
148     \texttt{ethers}   & corrispondenze fra numero IP e MAC address della
149                         scheda di rete.\\ 
150     \texttt{hosts}    & corrispondenze fra nome a dominio e numero IP.\\ 
151     \texttt{netgroup} & corrispondenze gruppo di rete e macchine che lo
152                         compongono.\\  
153     \texttt{networks} & corrispondenze fra nome di una rete e suo indirizzo
154                         IP.\\  
155     \texttt{protocols}& corrispondenze fra nome di un protocollo e relativo
156                         numero identificativo.\\ 
157     \texttt{rpc}      & corrispondenze fra nome di un servizio RPC e relativo 
158                         numero identificativo.\\ 
159     \texttt{services} & corrispondenze fra nome di un servizio e numero di
160                         porta. \\ 
161     \hline
162   \end{tabular}
163   \caption{Le diverse classi di corrispondenze definite
164     all'interno del \textit{Name Service Switch}.} 
165   \label{tab:sys_NSS_classes}
166 \end{table}
167
168 Il sistema  del \textit{Name Service  Switch} è controllato dal  contenuto del
169 file \file{/etc/nsswitch.conf}; questo contiene una riga\footnote{seguendo una
170   convezione  comune per  i  file  di configurazione  le  righe vuote  vengono
171   ignorate  e  tutto  quello  che  segue un  carattere  ``\texttt{\#}''  viene
172   considerato un  commento.} di configurazione per ciascuna  di queste classi,
173 che  viene inizia  col nome  di tab.~\ref{tab:sys_NSS_classes}  seguito  da un
174 carattere ``\texttt{:}'' e  prosegue con la lista dei  \textsl{servizi} su cui
175 le  relative informazioni sono  raggiungibili, scritti  nell'ordine in  cui si
176 vuole siano interrogati.
177
178 Ogni  servizio è  specificato  a sua  volta  da un  nome, come  \texttt{file},
179 \texttt{dns},  \texttt{db},  ecc.  che  identifica la  libreria  dinamica  che
180 realizza l'interfaccia  con esso. Per  ciascun servizio se \texttt{NAME}  è il
181 nome  utilizzato  dentro   \file{/etc/nsswitch.conf},  dovrà  essere  presente
182 (usualmente  in   \file{/lib})  una  libreria   \texttt{libnss\_NAME}  che  ne
183 implementa le funzioni.
184
185 In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
186 su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
187 fornire dal sistema del \textit{Name Service Switch}, dal punto di vista di un
188 programma che deve effettuare la risoluzione di un nome a dominio, tutto
189 quello che conta sono le funzioni classiche che il \textit{resolver} mette a
190 disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
191   tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
192 quelle che tratteremo nelle sezioni successive.
193
194
195 \subsection{Le funzioni di interrogazione del \textit{resolver}}
196 \label{sec:sock_resolver_functions}
197
198 Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
199 dominio conviene trattare in maniera più dettagliata il meccanismo principale
200 da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
201 benché in teoria sia solo uno dei possibili supporti su cui mantenere le
202 informazioni, in pratica costituisce il meccanismo principale con cui vengono
203 risolti i nomi a dominio.  Per questo motivo esistono una serie di funzioni di
204 libreria che servono specificamente ad esseguire delle interrogazioni verso un
205 server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
206 generiche di libreria usate anche dal sistema del \textit{resolver}.
207
208 Il sistema del DNS è in sostanza di un database distribuito organizzato in
209 maniera gerarchica, la manutenzione dei dati è mantenuta in tanti server
210 distinti ciascuno dei quali si occupa della risoluzione del proprio
211 \textsl{dominio}; i nomi a dominio sono poi organizzati in una struttura ad
212 albero analoga a quella dell'albero dei file in un sistema unix-like, con
213 domini di primo livello (come i \texttt{.org}), secondo livello (come
214 \texttt{.truelite.it}), ecc.  In questo caso le separazioni sono fra i vari
215 livelli sono definite dal carattere ``\texttt{.}''  ed i nomi devono essere
216 risolti da destra verso sinistra. Il meccanismo funziona con il criterio della
217 \textsl{delegazione}, un server responsabile per un dominio di primo livello
218 può delegare la risoluzione degli indirizzi per un suo dominio di secondo
219 livello ad un altro server, il quale a sua volta potrà delegare la risoluzione
220 di un eventuale sottodominio di terzo livello ad un altro server ancora.
221
222 In realtà un server DNS contiene comunque una serie di altre informazioni;
223 ciascuna voce nel database viene chiamata \textit{resource record}, e può
224 contenere diverse informazioni; in genere i \textit{resource record} vengono
225 classificati per la \textsl{classe di indirizzi} cui i dati contenuti fanno
226 riferimento, e per il \textsl{tipo} di questi ultimi. Oggigiorno i dati
227 mantenuti nei server DNS sono sostanzialmente relativi soltanto ad indirizzi
228 internet, per cui in pratica c'è soltanto una classe di indirizzi utilizzata,
229 i dati invece possono essere di vario tipo, uno dei quali è appunto la
230 corrispondenza fra nome a dominio e numero IP.
231
232 L'esistenza di vari tipi di informazioni ottenibili da un server DNS è
233 un'altro dei motivi per cui il \textit{resolver} prevede un insieme di
234 funzioni dedicato rispetto a quelle della semplice risoluzione dei nomi; la
235 prima di queste è \funcd{res\_init}, il cui prototipo è:
236 \begin{functions}
237 \headdecl{netinet/in.h}
238 \headdecl{arpa/nameser.h}
239 \headdecl{resolv.h}
240 \funcdecl{int res\_init(void)}
241
242 Inizializza il sistema del \textit{resolver}.
243
244 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
245   errore.}
246 \end{functions}
247
248 La funzione legge il contenuto dei file di configurazione per impostare il
249 dominio di default, gli indirizzi dei server DNS da contattare e l'ordine
250 delle ricerche; se non sono specificati server verrà utilizzato l'indirizzo
251 locale, e se non è definito un dominio di default sarà usato quello associato
252 con l'indirizzo locale. In genere si deve eseguire questa funzione prima di
253 chiamare tutte le altre. 
254
255 Le impostazioni del resolver e lo stato del sistema vengono mantenute in una
256 serie di variabili globali contenuti in una apposita struttura interna,
257 definita in \file{resolv.h}, che può essere acceduta una volta che la si
258 dichiara con:
259 \includecodesnip{listati/resolv_option.c}
260
261 Tutti i campi della struttura sono ad uso interno, l'unico che può essere
262 utile modificare è il campo \var{\_res.options}, che è una maschera binaria
263 che permette di controllare il comportamento del resolver, modificandone
264 alcune impostazioni direttamente da programma prima di invocare
265 \func{res\_init}. Le costanti che definiscono i vari bit di questo campo, con
266 il relativo significato sono illustrate in tab.~\ref{tab:resolver_option}, un
267 valore deve essere espresso con un opportuno OR aritmetico di dette costanti;
268 ad esempio il valore di default dato dalla costante \const{RES\_DEFAULT} è 
269 definito come: 
270 \includecodesnip{listati/resolv_option_def.c}
271
272 \begin{table}[htb]
273   \centering
274   \footnotesize
275   \begin{tabular}[c]{|l|p{8cm}|}
276     \hline
277     \textbf{Costante} & \textbf{Significato} \\
278     \hline
279     \hline
280     \const{RES\_INIT}       & viene attivato se è stata chiamata
281                               \func{res\_init}. \\
282     \const{RES\_DEBUG}      & stampa dei messaggi di debug.\\
283     \const{RES\_AAONLY}     & accetta solo risposte autoritative.\\
284     \const{RES\_USEVC}      & usa connessioni TCP per contattare i server 
285                               invece che l'usuale UDP.\\
286     \const{RES\_PRIMARY}    & interroga soltanto server DNS primari.
287                               \\
288     \const{RES\_IGNTC}      & ignora gli errori di troncamento, non ritenta la
289                               richiesta con una connessione TCP.\\
290     \const{RES\_RECURSE}    & imposta il bit che indica che si desidera
291                               eseguire una interrogazione ricorsiva.\\
292     \const{RES\_DEFNAMES}   & se attivo \func{res\_search} aggiunge il nome
293                               del dominio di default ai nomi singoli (che non
294                               contengono cioè un ``\texttt{.}'').\\
295     \const{RES\_STAYOPEN}   & usato con \const{RES\_USEVC} per mantenere
296                               aperte le connesioni TCP fra interrogazioni
297                               diverse. \\
298     \const{RES\_DNSRCH}     & se attivo \func{res\_search} esegue le ricerche
299                               di nomi di macchine nel dominio corrente o nei
300                               domini ad esso sovrastanti.\\
301     \const{RES\_INSECURE1}  & blocca i controlli di sicurezza di tipo 1.\\
302     \const{RES\_INSECURE2}  & blocca i controlli di sicurezza di tipo 2.\\
303     \const{RES\_NOALIASES}  & blocca l'uso della variabile di ambiente
304                               \texttt{HOSTALIASES}.\\ 
305     \const{RES\_USE\_INET6} & restituisce indirizzi IPv6 con
306                               \func{gethostbyname}. \\
307     \const{RES\_ROTATE}     & ruota la lista dei server DNS dopo ogni
308                               interrogazione.\\
309     \const{RES\_NOCHECKNAME}& non controlla i nomi per verificarne la
310                               correttezza sintattica. \\
311     \const{RES\_KEEPTSIG}   & non elimina i record di tipo \texttt{TSIG}.\\
312     \const{RES\_BLAST}      & \\
313     \const{RES\_DEFAULT}    & è l'insieme di \const{RES\_RECURSE},
314                               \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}.\\
315     \hline
316   \end{tabular}
317   \caption{Costanti utilizzabili come valori per \var{\_res.options}.}
318   \label{tab:resolver_option}
319 \end{table}
320
321 La funzione di richiesta principale è \funcd{res\_query}, che serve ad
322 eseguire una richiesta ad un server DNS per un nome a dominio completamente
323 specificato (quello che si chiama FQDN, \textit{Fully Qualified Domain Name});
324 il suo prototipo è:
325
326 \begin{functions}
327 \headdecl{netinet/in.h}
328 \headdecl{arpa/nameser.h}
329 \headdecl{resolv.h}
330 \funcdecl{int res\_query(const char *dname, int class, int type,
331               unsigned char *answer, int anslen)}
332
333   Esegue una interrogazione al DNS.
334
335 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
336   errore.}
337 \end{functions}
338
339
340 Per quanto ci interessa i tipi di \textit{resource record} che vengono
341 utilizzati dal \textit{resolver} sono sostanzialmente i seguenti:
342 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
343 \item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
344   indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
345   e l'indirizzo IP \texttt{62.48.34.25}.
346 \item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro
347   volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
348   fra un nome a dominio ed un indirizzo IPv6.
349 \item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
350   un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
351   per \textit{pointer}).
352 \item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
353   indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
354   \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
355   macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per
356   creare degli \textit{alias} in modo da associare un qualunque altro nome al
357   \textsl{nome canonico} della macchina (quello associato al record
358   \texttt{A}).
359 \end{basedescript}
360
361
362
363
364
365
366 Per questo motivo il \textit{resolver} prevede delle funzioni che permettono
367 sia di eseguire direttamente delle interrogazione ad un server DNS, che di
368 controllare le modalità con cui queste vengono eseguite; diventa così
369 possibile modificare da programma buona parte dei parametri controllati da
370 \file{/etc/resolv.conf}.
371
372
373
374 \subsection{La risoluzione dei nomi a dominio}
375 \label{sec:sock_gethostbyname}
376
377 Dato che la principale funzionalità del \textit{resolver} resta quella di
378 risolvere i nomi a dominio in indirizzi IP, vedremo per prime le funzioni a
379 questo dedicate. La prima funzione è \funcd{gethostbyname} il cui scopo è
380 ottenere l'indirizzo di una stazione noto il suo nome a dominio, il suo
381 prototipo è:
382 \begin{prototype}{netdb.h}
383 {struct hostent *gethostbyname(const char *name)}
384
385 Determina l'indirizzo associato al nome a dominio \param{name}.
386
387 \bodydesc{La funzione restituisce in caso di successo il puntatore ad una
388   struttura di tipo \struct{hostent} contente i dati associati al nome a
389   dominio o un puntatore nullo in caso di errore.}
390 \end{prototype}
391
392 La funzione prende come argomento una stringa \param{name} contenente il nome
393 a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
394 vengono memorizzati in una opportuna struttura \struct{hostent} la cui
395 definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. In caso di
396 insuccesso l'errore viene segnalato da un valore nullo del puntatore, ma in
397 questo caso, a differenza delle funzioni viste finora, non viene utilizzata la
398 variabile \var{errno} per riportare un codice di errore, in quanto questo
399 dipende solo dalle sottostanti chiamate al sistema e può non avere nessun
400 significato nell'indicare quale parte del procedimento di risoluzione è
401 fallita.
402
403 \begin{figure}[!htb]
404   \footnotesize \centering
405   \begin{minipage}[c]{15cm}
406     \includestruct{listati/hostent.h}
407   \end{minipage}
408   \caption{La struttura \structd{hostent}.}
409   \label{fig:sock_hostent_struct}
410 \end{figure}
411
412 Per questo motivo all'interno del resolver è stata definita una apposita
413 variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni di
414 libreria per indicare quale problema ha causato il fallimento della
415 risoluzione del nome. Ad essa si può accedere una volta che la si dichiara
416 con: 
417 \includecodesnip{listati/herrno.c} 
418 ed i valori che può assumere sono i seguenti:
419 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
420 \item[\const{HOST\_NOT\_FOUND}] l'indirizzo richiesto non è valido e la
421   macchina indicata è sconosciuta.
422 \item[\const{NO\_ADDRESS}] il nome a dominio richiesto è valido, ma non ha un
423   indirizzo associato ad esso (alternativamente può essere indicato come
424   \const{NO\_DATA}).
425 \item[\const{NO\_RECOVERY}] si è avuto un errore non recuperabile
426   nell'interrogazione di un server DNS.
427 \item[\const{TRY\_AGAIN}] si è avuto un errore temporaneo nell'interrogazione
428   di un server DNS, si può ritentare l'interrogazione in un secondo tempo. 
429 \end{basedescript}
430
431 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
432 effettuare la risoluzione del nome, è con i valori di questi record che
433 vengono riempite le varie parti della struttura \struct{hostent}. Il primo
434 campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
435   canonico}, che nel caso del DNS è appunto il nome associato ad un record
436 \texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
437 puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
438 puntatore del vettore punta ad una stringa contenente uno degli altri
439 possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel
440 DNS vengono inseriti come record di tipo \texttt{CNAME}).
441
442 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
443 che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
444 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
445 lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una
446 struttura 
447
448 Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
449 ai singoli indirizzi; il vettore è terminato da un puntatore nullo.  Inoltre,
450 come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
451 \var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
452 diretto al primo indirizzo della lista.
453
454 Oltre ai normali nomi a dominio la funzione accetta come argomento
455 \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
456 con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation}. In tal caso
457 \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma si
458 limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
459 corrispondente struttura \var{in\_addr} da indirizzara con
460 \code{h\_addr\_list[0]}.
461
462
463
464
465
466
467
468 \section{Le opzioni dei socket}
469 \label{sec:TCP_sock_options}
470
471 Finora abbiamo trattato i socket nel loro comportamento più comune, è però
472 possibile attivare alcune modalità diverse di funzionamento degli stessi
473
474 Dato che la maggior parte delle opzioni dei socket sono relative ai socket
475 TCP, ed hanno poi significato analogo quando usate con altri socket, abbiamo
476 preferito trattare l'argomento in generale in questa sezione piuttosto che nel
477 capitolo dedicato alla trattazione generica dei socket.
478
479 \section{Altre funzioni di controllo}
480 \label{sec:TCP_sock_ctrl}
481
482
483
484
485
486 %%% Local Variables: 
487 %%% mode: latex
488 %%% TeX-master: "gapil"
489 %%% End: