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
11 \chapter{La gestione dei socket}
12 \label{cha:sock_generic_management}
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
21 \section{La risoluzione dei nomi}
22 \label{sec:sock_name_resolution}
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 \textit{dotted
28 decimal} ad un numero. Vedremo in questa sezione le funzioni utilizzate per
29 poter utilizzare dei nomi simbolici al posto dei valori numerici, e viceversa
30 quelle che permettono di ottenere i nomi simbolici associati ad indirizzi,
31 porte o altre proprietà del sistema.
34 \subsection{La struttura del \textit{resolver}}
35 \label{sec:sock_resolver}
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.
51 \includegraphics[width=10cm]{img/resolver}
52 \caption{Schema di funzionamento delle routine del \textit{resolver}.}
53 \label{fig:sock_resolver_schema}
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}.
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 frecce 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ò interrogarne 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 mantenimento dei più vari tipi di informazioni su una
78 infrastruttura di questo tipo.}
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
88 Per questo aspetto il file di configurazione principale del sistema è
89 \file{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi IP
90 dei server DNS da contattare; a questo si affianca il file
91 \file{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui
92 eseguire la risoluzione dei nomi (se usare prima i valori di \file{/etc/hosts}
93 o quelli del DNS). Tralasciamo i dettagli relativi alle varie direttive che
94 possono essere usate in questi file, che si trovano nelle rispettive pagine di
97 Con il tempo però è divenuto possibile fornire diversi sostituti per
98 l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre
99 alla risoluzione dei nomi a dominio ci sono anche altri nomi da risolvere,
100 come quelli che possono essere associati ad una rete (invece che ad una
101 singola macchina) o ai gruppi di macchine definiti dal servizio
102 NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
103 Sun, e poi diffuso su tutte le piattaforme unix-like, che permette di
104 raggruppare all'interno di una rete (in quelli che appunto vengono chiamati
105 \textit{netgroup}) varie macchine, centralizzando i servizi di definizione
106 di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
107 da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
108 file statici \file{/etc/protocols} e \file{/etc/services}. Molte di queste
109 informazioni non si trovano su un DNS, ma in una rete locale può essere molto
110 utile centralizzare il mantenimento di alcune di esse su opportuni server.
111 Inoltre l'uso di diversi supporti possibili per le stesse informazioni (ad
112 esempio il nome delle macchine può essere mantenuto sia tramite
113 \file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema
114 dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni
115 classiche i vari supporti erano introdotti modificando direttamente le
116 funzioni di libreria, prevedendo un ordine di interrogazione predefinito e
117 non modificabile (a meno di una ricompilazione delle librerie stesse).}
119 Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
120 eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
121 generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
122 associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
123 introdotto la prima volta nelle librerie standard di Solaris, le \acr{glibc}
124 hanno ripreso lo stesso schema, si tenga presente che questo sistema non
125 esiste per altre librerie standard come le \acr{libc5} o le \acr{uclib}.}
126 cui abbiamo accennato anche in sez.~\ref{sec:sys_user_group} per quanto
127 riguarda la gestione dei dati associati a utenti e gruppi. Il \textit{Name
128 Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
129 sistema di librerie dinamiche che permette di definire in maniera generica sia
130 i supporti su cui mantenere i dati di corrispondenza fra nomi e valori
131 numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti
132 disponibili. Il sistema prevede una serie di possibili classi di
133 corrispondenza, quelle attualmente definite sono riportate in
134 tab.~\ref{tab:sys_NSS_classes}.
139 \begin{tabular}[c]{|l|p{8cm}|}
141 \textbf{Classe} & \textbf{Tipo di corrispondenza}\\
144 \texttt{shadow} & corrispondenze fra username e proprietà dell'utente
146 \texttt{group} & corrispondenze fra nome del gruppo e proprietà dello
148 \texttt{aliases} & alias per la posta elettronica\\
149 \texttt{ethers} & corrispondenze fra numero IP e MAC address della
151 \texttt{hosts} & corrispondenze fra nome a dominio e numero IP.\\
152 \texttt{netgroup} & corrispondenze gruppo di rete e macchine che lo
154 \texttt{networks} & corrispondenze fra nome di una rete e suo indirizzo
156 \texttt{protocols}& corrispondenze fra nome di un protocollo e relativo
157 numero identificativo.\\
158 \texttt{rpc} & corrispondenze fra nome di un servizio RPC e relativo
159 numero identificativo.\\
160 \texttt{services} & corrispondenze fra nome di un servizio e numero di
164 \caption{Le diverse classi di corrispondenze definite
165 all'interno del \textit{Name Service Switch}.}
166 \label{tab:sys_NSS_classes}
169 Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
170 file \file{/etc/nsswitch.conf}; questo contiene una riga\footnote{seguendo una
171 convezione comune per i file di configurazione le righe vuote vengono
172 ignorate e tutto quello che segue un carattere ``\texttt{\#}'' viene
173 considerato un commento.} di configurazione per ciascuna di queste classi,
174 che viene inizia col nome di tab.~\ref{tab:sys_NSS_classes} seguito da un
175 carattere ``\texttt{:}'' e prosegue con la lista dei \textsl{servizi} su cui
176 le relative informazioni sono raggiungibili, scritti nell'ordine in cui si
177 vuole siano interrogati.
179 Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
180 \texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che
181 realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
182 nome utilizzato dentro \file{/etc/nsswitch.conf}, dovrà essere presente
183 (usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
184 implementa le funzioni.
186 In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
187 su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
188 fornire dal sistema del \textit{Name Service Switch}, dal punto di vista di un
189 programma che deve effettuare la risoluzione di un nome a dominio, tutto
190 quello che conta sono le funzioni classiche che il \textit{resolver} mette a
191 disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
192 tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
193 quelle che tratteremo nelle sezioni successive.
196 \subsection{Le funzioni di interrogazione del \textit{resolver}}
197 \label{sec:sock_resolver_functions}
199 Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
200 dominio conviene trattare in maniera più dettagliata il meccanismo principale
201 da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
202 benché in teoria sia solo uno dei possibili supporti su cui mantenere le
203 informazioni, in pratica costituisce il meccanismo principale con cui vengono
204 risolti i nomi a dominio. Per questo motivo esistono una serie di funzioni di
205 libreria che servono specificamente ad eseguire delle interrogazioni verso un
206 server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
207 generiche di libreria usate anche dal sistema del \textit{resolver}.
209 Il sistema del DNS è in sostanza di un database distribuito organizzato in
210 maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno
211 dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a
212 dominio sono organizzati in una struttura ad albero analoga a quella
213 dell'albero dei file, con domini di primo livello (come i \texttt{.org}),
214 secondo livello (come \texttt{.truelite.it}), ecc. In questo caso le
215 separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}''
216 ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si
217 stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
218 ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
219 genere non viene mai scritto esplicitamente, ma che, come chiunque abbia
220 configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
221 \textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo
222 funziona con il criterio della \textsl{delegazione}, un server responsabile
223 per un dominio di primo livello può delegare la risoluzione degli indirizzi
224 per un suo dominio di secondo livello ad un altro server, il quale a sua volta
225 potrà delegare la risoluzione di un eventuale sottodominio di terzo livello ad
226 un altro server ancora.
228 In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
229 un nome a dominio in un indirizzo IP; ciascuna voce nel database viene
230 chiamata \textit{resource record}, e può contenere diverse informazioni. In
231 genere i \textit{resource record} vengono classificati per la \textsl{classe
232 di indirizzi} cui i dati contenuti fanno riferimento, e per il \textsl{tipo}
233 di questi ultimi.\footnote{ritroveremo classi di indirizzi e tipi di record
234 più avanti in tab.~\ref{tab:DNS_address_class} e
235 tab.~\ref{tab:DNS_record_type}.} Oggigiorno i dati mantenuti nei server DNS
236 sono quasi esclusivamente relativi ad indirizzi internet, per cui in pratica
237 viene utilizzata soltanto una classe di indirizzi; invece le corrispondenze
238 fra un nome a dominio ed un indirizzo IP sono solo uno fra i vari tipi di
239 informazione che un server DNS fornisce normalmente.
241 L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
242 \textit{resolver} prevede, rispetto a quelle relative alla semplice
243 risoluzione dei nomi, un insieme di funzioni specifiche dedicate
244 all'interrogazione di un server DNS; la prima di queste funzioni è
245 \funcd{res\_init}, il cui prototipo è:
247 \headdecl{netinet/in.h} \headdecl{arpa/nameser.h} \headdecl{resolv.h}
248 \funcdecl{int res\_init(void)}
250 Inizializza il sistema del \textit{resolver}.
252 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
256 La funzione legge il contenuto dei file di configurazione (i già citati
257 \file{resolv.conf} e \file{host.conf}) per impostare il dominio di default,
258 gli indirizzi dei server DNS da contattare e l'ordine delle ricerche; se non
259 sono specificati server verrà utilizzato l'indirizzo locale, e se non è
260 definito un dominio di default sarà usato quello associato con l'indirizzo
261 locale (ma questo può essere sovrascritto con l'uso della variabile di
262 ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
263 funzione direttamente in quanto viene automaticamente chiamata la prima volta
264 che si esegue una delle altre.
266 Le impostazioni e lo stato del \textit{resolver} vengono mantenuti in una
267 serie di variabili raggruppate nei campi di una apposita struttura \var{\_res}
268 usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
269 utilizzata internamente alle funzioni essendo definita come variabile globale;
270 questo consente anche di accedervi direttamente all'interno di un qualunque
271 programma, una volta che la sia opportunamente dichiarata come:
272 \includecodesnip{listati/resolv_option.c}
274 Tutti i campi della struttura sono ad uso interno, e vengono usualmente
275 inizializzati da \func{res\_init} in base al contenuto dei file di
276 configurazione e ad una serie di valori di default. L'unico campo che può
277 essere utile modificare è \var{\_res.options}, una maschera binaria che
278 contiene una serie di bit di opzione che permettono di controllare il
279 comportamento del \textit{resolver}.
284 \begin{tabular}[c]{|l|p{8cm}|}
286 \textbf{Costante} & \textbf{Significato} \\
289 \const{RES\_INIT} & viene attivato se è stata chiamata
291 \const{RES\_DEBUG} & stampa dei messaggi di debug.\\
292 \const{RES\_AAONLY} & accetta solo risposte autoritative.\\
293 \const{RES\_USEVC} & usa connessioni TCP per contattare i server
294 invece che l'usuale UDP.\\
295 \const{RES\_PRIMARY} & interroga soltanto server DNS primari.
297 \const{RES\_IGNTC} & ignora gli errori di troncamento, non ritenta la
298 richiesta con una connessione TCP.\\
299 \const{RES\_RECURSE} & imposta il bit che indica che si desidera
300 eseguire una interrogazione ricorsiva.\\
301 \const{RES\_DEFNAMES} & se attivo \func{res\_search} aggiunge il nome
302 del dominio di default ai nomi singoli (che non
303 contengono cioè un ``\texttt{.}'').\\
304 \const{RES\_STAYOPEN} & usato con \const{RES\_USEVC} per mantenere
305 aperte le connessioni TCP fra interrogazioni
307 \const{RES\_DNSRCH} & se attivo \func{res\_search} esegue le ricerche
308 di nomi di macchine nel dominio corrente o nei
309 domini ad esso sovrastanti.\\
310 \const{RES\_INSECURE1} & blocca i controlli di sicurezza di tipo 1.\\
311 \const{RES\_INSECURE2} & blocca i controlli di sicurezza di tipo 2.\\
312 \const{RES\_NOALIASES} & blocca l'uso della variabile di ambiente
313 \texttt{HOSTALIASES}.\\
314 \const{RES\_USE\_INET6} & restituisce indirizzi IPv6 con
315 \func{gethostbyname}. \\
316 \const{RES\_ROTATE} & ruota la lista dei server DNS dopo ogni
318 \const{RES\_NOCHECKNAME}& non controlla i nomi per verificarne la
319 correttezza sintattica. \\
320 \const{RES\_KEEPTSIG} & non elimina i record di tipo \texttt{TSIG}.\\
321 \const{RES\_BLAST} & \\
322 \const{RES\_DEFAULT} & è l'insieme di \const{RES\_RECURSE},
323 \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}.\\
326 \caption{Costanti utilizzabili come valori per \var{\_res.options}.}
327 \label{tab:resolver_option}
330 Per utilizzare questa funzionalità per modificare le impostazioni direttamente
331 da programma occorrerà impostare un opportuno valore per questo campo ed
332 invocare esplicitamente \func{res\_init}, dopo di che le altre funzioni
333 prenderanno le nuove impostazioni. Le costanti che definiscono i vari bit di
334 questo campo, ed il relativo significato sono illustrate in
335 tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
336 deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
337 esempio il valore di default delle opzioni, espresso dalla costante
338 \const{RES\_DEFAULT}, è definito come:
339 \includecodesnip{listati/resolv_option_def.c}
341 Non tratteremo il significato degli altri campi non essendovi necessità di
342 modificarli direttamente; gran parte di essi sono infatti impostati dal
343 contenuto dei file di configurazione, mentre le funzionalità controllate da
344 alcuni di esse possono essere modificate con l'uso delle opportune variabili
345 di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
346 \texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
347 controlla quante volte viene ripetuto il tentativo di connettersi ad un server
348 DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
349 significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
350 soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
351 della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
352 valore preso come base (in numero di secondi) per definire la scadenza di una
353 richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
354 il tempo di scadenza per il numero massimo di volte stabilito da
357 La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
358 eseguire una richiesta ad un server DNS per un nome a dominio
359 \textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
360 Qualified Domain Name}); il suo prototipo è:
363 \headdecl{netinet/in.h}
364 \headdecl{arpa/nameser.h}
366 \funcdecl{int res\_query(const char *dname, int class, int type,
367 unsigned char *answer, int anslen)}
369 Esegue una interrogazione al DNS.
371 \bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei
372 dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di
376 La funzione esegue una interrogazione ad un server DNS relativa al nome da
377 risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve
378 essere specificata la classe di indirizzi in cui eseguire la ricerca con
379 \param{class}, ed il tipo di \textit{resource record} che si vuole ottenere
380 con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
381 lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
382 allocato in precedenza.
385 Una seconda funzione di ricerca, analoga a \func{res\_query}, che prende gli
386 stessi argomenti, ma che esegue l'interrogazione con le funzionalità
387 addizionali previste dalle due opzioni \const{RES\_DEFNAMES} e
388 \const{RES\_DNSRCH}, è \funcd{res\_search}, il cui prototipo è:
390 \headdecl{netinet/in.h}
391 \headdecl{arpa/nameser.h}
393 \funcdecl{int res\_search(const char *dname, int class, int type,
394 unsigned char *answer, int anslen)}
396 Esegue una interrogazione al DNS.
398 \bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei
399 dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di
403 In sostanza la funzione ripete una serie di chiamate a \func{res\_query}
404 aggiungendo al nome contenuto nella stringa \param{dname} il dominio di
405 default da cercare, fermandosi non appena trova un risultato. Il risultato di
406 entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
407 seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
408 programma (o di altre funzioni) estrarre i relativi dati, esistono una serie
409 di funzioni interne usate per la scansione di questi dati, per chi fosse
410 interessato una trattazione dettagliata è riportata nel quattordicesimo
411 capitolo di \cite{DNSbind}.
413 Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in
414 pratica oggi viene utilizzata soltanto quella degli indirizzi internet; le
415 costanti che identificano dette classi, da usare come valore per l'argomento
416 \param{class} delle precedenti funzioni, sono riportate in
417 tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
418 \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
423 \begin{tabular}[c]{|l|p{8cm}|}
425 \textbf{Costante} & \textbf{Significato} \\
428 \const{C\_IN} & indirizzi internet, in pratica i soli utilizzati oggi.\\
429 \const{C\_HS} & indirizzi \textit{Hesiod}, utilizzati solo al MIT, oggi
430 completamente estinti. \\
431 \const{C\_CHAOS}& indizzi per la rete \textit{Chaosnet}, un'altra rete
432 sperimentale nata al MIT. \\
433 \const{C\_ANY} & indica un indirizzo di classe qualunque.\\
436 \caption{Costanti identificative delle classi di indirizzi per l'argomento
437 \param{class} di \func{res\_query}.}
438 \label{tab:DNS_address_class}
441 Come accennato le tipologie di dati che sono mantenibili su un server DNS sono
442 diverse, ed a ciascuna di essa corrisponde un diverso tipo di \textit{resource
443 record}. L'elenco delle costanti\footnote{ripreso dai file di dichiarazione
444 \file{arpa/nameser.h} e \file{arpa/nameser\_compat.h}.} che definiscono i
445 valori che si possono usare per l'argomento \param{type} per specificare il
446 tipo di \textit{resource record} da richiedere è riportato in
447 tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
448 hanno gli stessi nomi usati per identificare i record nei file di zona di
449 BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
450 implementazione di un server DNS, ed, essendo utilizzata nella stragrande
451 maggioranza dei casi, fa da riferimento; i dati relativi ad un certo
452 dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
453 che sono usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo
454 di dominio è identificato da un nome che è appunto identico a quello delle
455 costanti di tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.}
456 e che normalmente sono anche usati come nomi per indicare i record.
461 \begin{tabular}[c]{|l|l|}
463 \textbf{Costante} & \textbf{Significato} \\
466 \const{T\_A} & indirizzo di una stazione.\\
467 \const{T\_NS} & server DNS autoritativo per il dominio richiesto.\\
468 \const{T\_MD} & destinazione per la posta elettronica.\\
469 \const{T\_MF} & redistributore per la posta elettronica.\\
470 \const{T\_CNAME} & nome canonico.\\
471 \const{T\_SOA} & inizio di una zona di autorità.\\
472 \const{T\_MB} & nome a dominio di una casella di posta.\\
473 \const{T\_MG} & nome di un membro di un gruppo di posta.\\
474 \const{T\_MR} & nome di un cambiamento di nome per la posta.\\
475 \const{T\_NULL} & record nullo.\\
476 \const{T\_WKS} & servizio noto.\\
477 \const{T\_PTR} & risoluzione inversa di un indirizzo numerico.\\
478 \const{T\_HINFO} & informazione sulla stazione.\\
479 \const{T\_MINFO} & informazione sulla casella di posta.\\
480 \const{T\_MX} & server cui instradare la posta per il dominio.\\
481 \const{T\_TXT} & stringhe di testo (libere).\\
482 \const{T\_RP} & nome di un responsabile (\textit{responsible person}).\\
483 \const{T\_AFSDB} & database per una cella AFS.\\
484 \const{T\_X25} & indirizzo di chiamata per X.25.\\
485 \const{T\_ISDN} & indirizzo di chiamata per ISDN.\\
486 \const{T\_RT} & router.\\
487 \const{T\_NSAP} & indirizzo NSAP.\\
488 \const{T\_NSAP\_PTR}& risoluzione inversa per NSAP (deprecato).\\
489 \const{T\_SIG} & firma digitale di sicurezza.\\
490 \const{T\_KEY} & chiave per firma.\\
491 \const{T\_PX} & corrispondenza per la posta X.400.\\
492 \const{T\_GPOS} & posizione geografica.\\
493 \const{T\_AAAA} & indirizzo IPv6.\\
494 \const{T\_LOC} & informazione di collocazione.\\
495 \const{T\_NXT} & dominio successivo.\\
496 \const{T\_EID} & identificatore di punto conclusivo.\\
497 \const{T\_NIMLOC}& posizionatore \textit{nimrod}.\\
498 \const{T\_SRV} & servizio.\\
499 \const{T\_ATMA} & indirizzo ATM.\\
500 \const{T\_NAPTR} & puntatore ad una \textit{naming authority} .\\
501 \const{T\_TSIG} & firma di transazione.\\
502 \const{T\_IXFR} & trasferimento di zona incrementale.\\
503 \const{T\_AXFR} & trasferimento di zona di autorità.\\
504 \const{T\_MAILB} & trasferimento di record di caselle di posta.\\
505 \const{T\_MAILA} & trasferimento di record di server di posta.\\
506 \const{T\_ANY} & valore generico.\\
509 \caption{Costanti identificative del tipo di record per l'argomento
510 \param{type} di \func{res\_query}.}
511 \label{tab:DNS_record_type}
515 L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
516 \textit{resource record} definiti, con una breve descrizione del relativo
517 significato. Di tutti questi però viene impiegato correntemente solo un
518 piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati
519 applicativi che non ci interessano non avendo nulla a che fare con la
520 risoluzione degli indirizzi IP, pertanto non entreremo nei dettagli del
521 significato di tutti i \textit{resource record}, ma solo di quelli usati dalle
522 funzioni del \textit{resolver}. Questi sono sostanzialmente i seguenti (per
523 indicarli si è usata la notazione dei file di zona di BIND):
524 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
525 \item[\texttt{A}] viene usato per indicare la corrispondenza fra un nome a
526 dominio ed un indirizzo IPv4; ad esempio la corrispondenza fra
527 \texttt{dodds.truelite.it} e l'indirizzo IP \texttt{62.48.34.25}.
528 \item[\texttt{AAAA}] viene usato per indicare la corrispondenza fra un nome a
529 dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
530 dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
531 \item[\texttt{PTR}] per fornire la corrispondenza inversa fra un indirizzo IP
532 ed un nome a dominio ad esso associato si utilizza questo tipo di record (il
533 cui nome sta per \textit{pointer}).
534 \item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
535 stesso indirizzo (come ad esempio \texttt{www.truelite.it}, o
536 \texttt{sources.truelite.it}, che fanno sempre riferimento a
537 \texttt{dodds.truelite.it}) si può usare questo tipo di record per creare
538 degli \textit{alias} in modo da associare un qualunque altro nome al
539 \textsl{nome canonico} della macchina (si chiama così quello associato al
543 Come accennato in caso di successo le due funzioni di richiesta restituiscono
544 il risultato della interrogazione al server, in caso di insuccesso l'errore
545 invece viene segnalato da un valore di ritorno pari a -1, ma in questo caso,
546 non può essere utilizzata la variabile \var{errno} per riportare un codice di
547 errore, in quanto questo viene impostato per ciascuna delle chiamate al
548 sistema utilizzate dalle funzioni del \textit{resolver}, non avrà alcun
549 significato nell'indicare quale parte del procedimento di risoluzione è
552 Per questo motivo è stata definita una variabile di errore separata,
553 \var{h\_errno}, che viene utilizzata dalle funzioni del \textit{resolver} per
554 indicare quale problema ha causato il fallimento della risoluzione del nome.
555 Ad essa si può accedere una volta che la si dichiara con:
556 \includecodesnip{listati/herrno.c}
557 ed i valori che può assumere, con il relativo significato, sono riportati in
558 tab.~\ref{tab:h_errno_values}.
563 \begin{tabular}[c]{|l|p{10cm}|}
565 \textbf{Costante} & \textbf{Significato} \\
568 \const{HOST\_NOT\_FOUND} & l'indirizzo richiesto non è valido e la
569 macchina indicata è sconosciuta. \\
570 \const{NO\_ADDRESS} & il nome a dominio richiesto è valido, ma non ha
571 un indirizzo associato ad esso
572 (alternativamente può essere indicato come
573 \const{NO\_DATA}). \\
574 \const{NO\_RECOVERY} & si è avuto un errore non recuperabile
575 nell'interrogazione di un server DNS. \\
576 \const{TRY\_AGAIN} & si è avuto un errore temporaneo
577 nell'interrogazione di un server DNS, si può
578 ritentare l'interrogazione in un secondo
582 \caption{Valori possibili della variabile \var{h\_errno}.}
583 \label{tab:h_errno_values}
586 Insieme alla nuova variabile vengono definite anche due nuove funzioni per
587 stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror}
588 per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima è
589 \funcd{herror} ed il suo prototipo è:
592 \funcdecl{void herror(const char *string)}
594 Stampa un errore di risoluzione.
597 La funzione è l'analoga di \func{perror} e stampa sullo standard error un
598 messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui
599 viene anteposta la stringa \param{string} passata come argomento. La seconda
600 funzione è \funcd{hstrerror} ed il suo prototipo è:
603 \funcdecl{const char *hstrerror(int err)}
605 Restituisce una stringa corrispondente ad un errore di risoluzione.
607 \noindent che, come l'analoga \func{strerror}, restituisce una stringa con un
608 messaggio di errore già formattato, corrispondente al codice passato come
609 argomento (che si presume sia dato da \var{h\_errno}).
614 \subsection{La risoluzione dei nomi a dominio}
615 \label{sec:sock_name_services}
617 La principale funzionalità del \textit{resolver} resta quella di risolvere i
618 nomi a dominio in indirizzi IP, per cui non ci dedicheremo oltre alle funzioni
619 di richiesta generica ed esamineremo invece le funzioni a questo dedicate. La
620 prima funzione è \funcd{gethostbyname} il cui scopo è ottenere l'indirizzo di
621 una stazione noto il suo nome a dominio, il suo prototipo è:
622 \begin{prototype}{netdb.h}
623 {struct hostent *gethostbyname(const char *name)}
625 Determina l'indirizzo associato al nome a dominio \param{name}.
627 \bodydesc{La funzione restituisce in caso di successo il puntatore ad una
628 struttura di tipo \struct{hostent} contenente i dati associati al nome a
629 dominio, o un puntatore nullo in caso di errore.}
632 La funzione prende come argomento una stringa \param{name} contenente il nome
633 a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
634 vengono memorizzati in una opportuna struttura \struct{hostent} la cui
635 definizione è riportata in fig.~\ref{fig:sock_hostent_struct}.
638 \footnotesize \centering
639 \begin{minipage}[c]{15cm}
640 \includestruct{listati/hostent.h}
642 \caption{La struttura \structd{hostent} per la risoluzione dei nomi a
643 dominio e degli indirizzi IP.}
644 \label{fig:sock_hostent_struct}
647 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
648 effettuare la risoluzione del nome, è con i valori contenuti nei relativi
649 record che vengono riempite le varie parti della struttura \struct{hostent}.
650 Il primo campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
651 canonico}, che nel caso del DNS è appunto il nome associato ad un record
652 \texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
653 puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
654 puntatore del vettore punta ad una stringa contenente uno degli altri
655 possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel
656 DNS vengono inseriti come record di tipo \texttt{CNAME}).
658 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
659 che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
660 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
661 lunghezza dell'indirizzo stesso in byte.
663 Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
664 ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre,
665 come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
666 \var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
667 diretto al primo indirizzo della lista.
669 Oltre ai normali nomi a dominio la funzione accetta come argomento
670 \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
671 con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation} per IPv6. In
672 tal caso \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma
673 si limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
674 corrispondente struttura \var{in\_addr} da indirizzare con
675 \code{h\_addr\_list[0]}.
677 Con l'uso di \func{gethostbyname} normalmente si ottengono solo gli indirizzi
678 IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
679 l'opzione \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e poi
680 chiamare \func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per
681 modificare le opzioni del resolver; dato che questo non è molto comodo è stata
682 definita\footnote{questa è una estensione fornita dalle \acr{glibc},
683 disponibile anche in altri sistemi unix-like.} un'altra funzione,
684 \funcd{gethostbyname2}, il cui prototipo è:
687 \headdecl{sys/socket.h}
688 \funcdecl{struct hostent *gethostbyname2(const char *name, int af)}
690 Determina l'indirizzo di tipo \param{af} associato al nome a dominio
693 \bodydesc{La funzione restituisce in caso di successo il puntatore ad una
694 struttura di tipo \struct{hostent} contenente i dati associati al nome a
695 dominio, o un puntatore nullo in caso di errore.}
698 In questo caso la funzione prende un secondo argomento \param{af} che indica
699 (i soli valori consentiti sono \const{AF\_INET} o \const{AF\_INET6}, per
700 questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
701 che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
702 il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
706 \footnotesize \centering
707 \begin{minipage}[c]{15cm}
708 \includecodesample{listati/mygethost.c}
711 \caption{Esempio di codice per la risoluzione di un indirizzo.}
712 \label{fig:mygethost_example}
715 Vediamo allora un primo esempio dell'uso delle funzioni di risoluzione, in
716 fig.~\ref{fig:mygethost_example} è riportato un estratto del codice di un
717 programma che esegue una semplice interrogazione al \textit{resolver} usando
718 \func{gethostbyname} e poi ne stampa a video i risultati. Al solito il
719 sorgente completo, che comprende il trattamento delle opzioni ed una funzione
720 per stampare un messaggio di aiuto, è nel file \texttt{mygethost.c} dei
721 sorgenti allegati alla guida.
723 Il programma richiede un solo argomento che specifichi il nome da cercare,
724 senza il quale (\texttt{\small 12--15}) esce con un errore. Dopo di che
725 (\texttt{\small 16}) si limita a chiamare \func{gethostbyname}, ricevendo il
726 risultato nel puntatore \var{data}. Questo (\texttt{\small 17--20}) viene
727 controllato per rilevare eventuali errori, nel qual caso il programma esce
728 dopo aver stampato un messaggio con \func{herror}.
730 Se invece la risoluzione è andata a buon fine si inizia (\texttt{\small 21})
731 con lo stampare il nome canonico, dopo di che (\texttt{\small 22--26}) si
732 stampano eventuali altri nomi. Per questo prima (\texttt{\small 22}) si prende
733 il puntatore alla cima della lista che contiene i nomi e poi (\texttt{\small
734 23--26}) si esegue un ciclo che sarà ripetuto fin tanto che nella lista si
735 troveranno dei puntatori validi\footnote{si ricordi che la lista viene
736 terminata da un puntatore nullo.} per le stringhe dei nomi; prima
737 (\texttt{\small 24}) si stamperà la stringa e poi (\texttt{\small 25}) si
738 provvederà ad incrementare il puntatore per passare al successivo elemento
741 Una volta stampati i nomi si passerà a stampare gli indirizzi, il primo passo
742 (\texttt{\small 27--34}) è allora quello di riconoscere il tipo di indirizzo
743 sulla base del valore del campo \var{h\_addrtype}, stampandolo a video. Si è
744 anche previsto di stampare un errore nel caso (che non dovrebbe mai accadere)
745 di un indirizzo non valido.
747 Infine (\texttt{\small 35--40}) si stamperanno i valori degli indirizzi, di
748 nuovo (\texttt{\small 35}) si inizializzerà un puntatore alla cima della lista
749 e si eseguirà un ciclo fintanto che questo punterà ad indirizzi validi in
750 maniera analoga a quanto fatto in precedenza per i nomi a dominio. Si noti
751 come, essendo il campo \var{h\_addr\_list} un puntatore ad strutture di
752 indirizzi generiche, questo sia ancora di tipo \texttt{char **} e si possa
753 riutilizzare lo stesso puntatore usato per i nomi.
755 Per ciascun indirizzo valido si provvederà (\texttt{\small 37}) ad una
756 conversione con la funzione \func{inet\_ntop} (vedi
757 sez.~\ref{sec:sock_addr_func}) passandole gli opportuni argomenti, questa
758 restituirà la stringa da stampare (\texttt{\small 38}) con il valore
759 dell'indirizzo in \var{buffer}, che si è avuto la cura di dichiarare
760 inizialmente (\texttt{\small 10}) con dimensioni adeguate; dato che la
761 funzione è in grado di tenere conto automaticamente del tipo di indirizzo non
762 ci sono precauzioni particolari da prendere.\footnote{volendo essere pignoli
763 si dovrebbe controllarne lo stato di uscita, lo si è tralasciato per non
764 appesantire il codice, dato che in caso di indirizzi non validi si sarebbe
765 avuto un errore con \func{gethostbyname}, ma si ricordi che la sicurezza non
768 Le funzioni illustrate finora hanno un difetto: utilizzando una area di
769 memoria interna per allocare i contenuti della struttura \struct{hostent} non
770 possono essere rientranti. Questo comporta anche che in due successive
771 chiamate i dati potranno essere sovrascritti. Si tenga presente poi che
772 copiare il contenuto della sola struttura non è sufficiente per salvare tutti
773 i dati, in quanto questa contiene puntatori ad altri dati, che pure possono
774 essere sovrascritti; per questo motivo, se si vuole salvare il risultato di
775 una chiamata, occorrerà eseguire quella che si chiama una
776 \index{\textit{deep~copy}}\textit{deep copy}.\footnote{si chiama così quella
777 tecnica per cui, quando si deve copiare il contenuto di una struttura
778 complessa (con puntatori che puntano ad altri dati, che a loro volta possono
779 essere puntatori ad altri dati) si deve copiare non solo il contenuto della
780 struttura, ma eseguire una scansione per risolvere anche tutti i puntatori
781 contenuti in essa (e così via se vi sono altre sottostrutture con altri
782 puntatori) e copiare anche i dati da questi referenziati.}
784 Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
785 versioni rientranti delle precedenti funzioni, al solito queste sono
786 caratterizzate dall'avere un suffisso \texttt{\_r}, pertanto avremo le due
787 funzioni \funcd{gethostbyname\_r} e \funcd{gethostbyname2\_r} i cui prototipi
791 \headdecl{sys/socket.h}
792 \funcdecl{int gethostbyname\_r(const char *name, struct hostent *ret,
793 char *buf, size\_t buflen, struct hostent **result, int *h\_errnop)}
794 \funcdecl{int gethostbyname2\_r(const char *name, int af,
795 struct hostent *ret, char *buf, size\_t buflen,
796 struct hostent **result, int *h\_errnop)}
798 Versioni rientranti delle funzioni \func{gethostbyname} e
799 \func{gethostbyname2}.
801 \bodydesc{Le funzioni restituiscono 0 in caso di successo ed un valore
802 negativo in caso di errore.}
805 Gli argomenti \param{name} (e \param{af} per \func{gethostbyname2\_r}) hanno
806 lo stesso significato visto in precedenza. Tutti gli altri argomenti hanno lo
807 stesso significato per entrambe le funzioni. Per evitare l'uso di variabili
808 globali si dovrà allocare preventivamente una struttura \struct{hostent} in
809 cui ricevere il risultato, passandone l'indirizzo alla funzione nell'argomento
810 \param{ret}. Inoltre, dato che \struct{hostent} contiene dei puntatori, dovrà
811 essere allocato anche un buffer in cui le funzioni possano scrivere tutti i
812 dati del risultato dell'interrogazione da questi puntati; l'indirizzo e la
813 lunghezza di questo buffer devono essere indicati con gli argomenti
814 \param{buf} e \param{buflen}.
816 Gli ultimi due argomenti vengono utilizzati per avere indietro i risultati
817 come \index{\textit{value~result~argument}}\textit{value result argument}, si
818 deve specificare l'indirizzo della variabile su cui la funzione dovrà salvare
819 il codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
820 puntatore che si userà per accedere i dati con \param{result}.
822 In caso di successo entrambe le funzioni restituiscono un valore nullo,
823 altrimenti restituiscono un codice di errore negativo e all'indirizzo puntato
824 da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
825 \param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
826 essere rientrante la funzione non può la variabile globale \var{h\_errno}. In
827 questo caso il codice di errore, oltre ai valori di
828 tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
829 qualora il buffer allocato su \param{buf} non sia sufficiente a contenere i
830 dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
831 con un buffer di dimensione maggiore.
833 Una delle caratteristiche delle interrogazioni al servizio DNS è che queste
834 sono normalmente eseguite con il protocollo UDP, ci sono casi in cui si
835 preferisce che vengano usate connessioni permanenti con il protocollo TCP. Per
836 ottenere questo\footnote{si potrebbero impostare direttamente le opzioni di
837 \var{\_\_res.options}, ma queste funzioni permettono di semplificare la
838 procedura.} sono previste delle funzioni apposite; la prima è
839 \funcd{sethostent}, il cui prototipo è:
840 \begin{prototype}{netdb.h}
841 {void sethostent(int stayopen)}
843 Richiede l'uso di connessioni per le interrogazioni ad un server DNS.
845 \bodydesc{La funzione non restituisce nulla.}
848 La funzione permette di richiedere l'uso di connessioni TCP per la richiesta
849 dei dati, e che queste restino aperte per successive richieste. Il valore
850 dell'argomento \param{stayopen} indica se attivare questa funzionalità, un
851 valore pari a 1 (o diverso da zero), che indica una condizione vera in C,
852 attiva la funzionalità. Come si attiva l'uso delle connessioni TCP lo si può
853 disattivare con la funzione \funcd{endhostent}; il suo prototipo è:
854 \begin{prototype}{netdb.h}
855 {void endhostent(void)}
857 Disattiva l'uso di connessioni per le interrogazioni ad un server DNS.
859 \bodydesc{La funzione non restituisce nulla.}
861 \noindent e come si può vedere la funzione è estremamente semplice, non
862 richiedendo nessun argomento.
865 Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
866 per ottenerne il nome a dominio ad esso associato, per fare questo si può
867 usare la funzione \funcd{gethostbyaddr}, il cui prototipo è:
870 \headdecl{sys/socket.h}
871 \funcdecl{struct hostent *gethostbyaddr(const char *addr, int len, int type)}
873 Richiede la risoluzione inversa di un indirizzo IP.
875 \bodydesc{La funzione restituisce l'indirizzo ad una struttura
876 \struct{hostent} in caso di successo ed \const{NULL} in caso di errore.}
879 In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
880 appropriata struttura contenente il valore dell'indirizzo IP (o IPv6) che si
881 vuole risolvere. L'uso del tipo \type{char *} per questo argomento è storico,
882 il dato dovrà essere fornito in una struttura \struct{in\_addr}\footnote{si
883 ricordi che, come illustrato in fig.~\ref{fig:sock_sa_ipv4_struct}, questo
884 in realtà corrisponde ad un numero intero, da esprimere comunque in
885 \textit{network order}, non altrettanto avviene però per \var{in6\_addr},
886 pertanto è sempre opportuno inizializzare questi indirizzi con
887 \func{inet\_pton} (vedi sez.~\ref{sec:sock_conv_func_gen}).} per un
888 indirizzo IPv4 ed una struttura \struct{in6\_addr} per un indirizzo IPv6,
889 mentre in \param{len} se ne dovrà specificare la dimensione (rispettivamente 4
890 o 16), infine l'argomento \param{type} indica il tipo di indirizzo e dovrà
891 essere o \const{AF\_INET} o \const{AF\_INET6}.
893 La funzione restituisce, in caso di successo, un puntatore ad una struttura
894 \struct{hostent}, solo che in questo caso la ricerca viene eseguita
895 richiedendo al DNS un record di tipo \texttt{PTR} corrispondente all'indirizzo
896 specificato. In caso di errore al solito viene usata la variabile
897 \var{h\_errno} per restituire un opportuno codice. In questo caso l'unico
898 campo del risultato che interessa è \var{h\_name} che conterrà il nome a
899 dominio, la funziona comunque inizializza anche il primo campo della lista
900 \var{h\_addr\_list} col valore dell'indirizzo passato come argomento.
902 Per risolvere il problema dell'uso da parte delle due funzioni
903 \func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
904 sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
905 indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
906 con \func{gethostbyname}), vennero introdotte due nuove funzioni di
907 risoluzione,\footnote{le funzioni sono presenti nelle \acr{glibc} versione
908 2.1.96, ma essendo considerate deprecate (vedi
909 sez.~\ref{sec:sock_advanced_name_services}) sono state rimosse nelle
910 versioni successive.} \funcd{getipnodebyname} e \funcd{getipnodebyaddr}, i
914 \headdecl{sys/types.h}
915 \headdecl{sys/socket.h}
917 \funcdecl{struct hostent *getipnodebyname(const char *name, int af, int
918 flags, int *error\_num)}
920 \funcdecl{struct hostent *getipnodebyaddr(const void *addr, size\_t len,
921 int af, int *error\_num)}
923 Richiedono rispettivamente la risoluzione e la risoluzione inversa di un
926 \bodydesc{Entrambe le funzioni restituiscono l'indirizzo ad una struttura
927 \struct{hostent} in caso di successo ed \const{NULL} in caso di errore.}
930 Entrambe le funzioni supportano esplicitamente la scelta di una famiglia di
931 indirizzi con l'argomento \param{af} (che può assumere i valori
932 \const{AF\_INET} o \const{AF\_INET6}), e restituiscono un codice di errore
933 (con valori identici a quelli precedentemente illustrati in
934 tab.~\ref{tab:h_errno_values}) nella variabile puntata da \param{error\_num}.
935 La funzione \func{getipnodebyaddr} richiede poi che si specifichi l'indirizzo
936 come per \func{gethostbyaddr} passando anche la lunghezza dello stesso
937 nell'argomento \param{len}.
939 La funzione \func{getipnodebyname} prende come primo argomento il nome da
940 risolvere, inoltre prevede un apposito argomento \param{flags}, da usare come
941 maschera binaria, che permette di specificarne il comportamento nella
942 risoluzione dei diversi tipi di indirizzi (IPv4 e IPv6); ciascun bit
943 dell'argomento esprime una diversa opzione, e queste possono essere specificate
944 con un OR aritmetico delle costanti riportate in
945 tab.~\ref{tab:sock_getipnodebyname_flags}.
950 \begin{tabular}[c]{|l|p{10cm}|}
952 \textbf{Costante} & \textbf{Significato} \\
955 \const{AI\_V4MAPPED} & usato con \const{AF\_INET6} per richiedere una
956 ricerca su un indirizzo IPv4 invece che IPv6; gli
957 eventuali risultati saranno rimappati su indirizzi
959 \const{AI\_ALL} & usato con \const{AI\_V4MAPPED}; richiede sia
960 indirizzi IPv4 che IPv6, e gli indirizzi IPv4
961 saranno rimappati in IPv6.\\
962 \const{AI\_ADDRCONFIG}& richiede che una richiesta IPv4 o IPv6 venga
963 eseguita solo se almeno una interfaccia del
964 sistema è associata ad un indirizzo di tale tipo.\\
965 \const{AI\_DEFAULT} & il valore di default, è equivalente alla
966 combinazione di \const{AI\_ADDRCONFIG} e di
967 \const{AI\_V4MAPPED)}.\\
970 \caption{Valori possibili per i bit dell'argomento \param{flags} della
971 funzione \func{getipnodebyname}.}
972 \label{tab:sock_getipnodebyname_flags}
975 Entrambe le funzioni restituiscono un puntatore ad una struttura \var{hostent}
976 che contiene i risultati della ricerca, che viene allocata dinamicamente
977 insieme a tutto lo spazio necessario a contenere i dati in essa referenziati;
978 per questo motivo queste funzioni non soffrono dei problemi dovuti all'uso di
979 una sezione statica di memoria presenti con le precedenti \func{gethostbyname}
980 e \func{gethostbyaddr}. L'uso di una allocazione dinamica però comporta anche
981 la necessità di deallocare esplicitamente la memoria occupata dai risultati
982 una volta che questi non siano più necessari; a tale scopo viene fornita la
983 funzione \funcd{freehostent}, il cui prototipo è:
986 \headdecl{sys/types.h}
987 \headdecl{sys/socket.h}
989 \funcdecl{void freehostent(struct hostent *ip)}
991 Disalloca una struttura \var{hostent}.
993 \bodydesc{La funzione non ritorna nulla.}
996 La funzione permette di disallocare una struttura \var{hostent}
997 precedentemente allocata in una chiamata di \func{getipnodebyname} o
998 \func{getipnodebyaddr}, e prende come argomento l'indirizzo restituito da una
1001 Infine per concludere la nostra panoramica sulle funzioni di risoluzione dei
1002 nomi dobbiamo citare le funzioni che permettono di interrogare gli altri
1003 servizi di risoluzione dei nomi illustrati in sez.~\ref{sec:sock_resolver}; in
1004 generale infatti ci sono una serie di funzioni nella forma
1005 \texttt{getXXXbyname} e \texttt{getXXXbyaddr} per ciascuna delle informazioni
1006 di rete mantenute dal \textit{Name Service Switch} che permettono
1007 rispettivamente di trovare una corrispondenza cercando per nome o per numero.
1009 L'elenco di queste funzioni è riportato nelle colonne finali di
1010 tab.~\ref{tab:name_resolution_functions}, dove le si sono suddivise rispetto
1011 al tipo di informazione che forniscono (riportato in prima colonna). Nella
1012 tabella si è anche riportato il file su cui vengono ordinariamente mantenute
1013 queste informazioni, che però può essere sostituito da un qualunque supporto
1014 interno al \textit{Name Service Switch} (anche se usualmente questo avviene
1015 solo per la risoluzione degli indirizzi). Ciascuna funzione fa riferimento ad
1016 una sua apposita struttura che contiene i relativi dati, riportata in terza
1022 \begin{tabular}[c]{|l|l|l|l|l|}
1024 \textbf{Informazione}&\textbf{File}&\textbf{Struttura}&
1025 \multicolumn{2}{|c|}{\textbf{Funzioni}}\\
1028 indirizzo&\file{/etc/hosts}&\struct{hostent}&\func{gethostbyname}&
1029 \func{gethostbyaddr}\\
1030 servizio &\file{/etc/services}&\struct{servent}&\func{getservbyname}&
1031 \func{getservbyaddr}\\
1032 rete &\file{/etc/networks}&\struct{netent}&\func{getnetbyname}&
1033 \func{getnetbyaddr}\\
1034 protocollo&\file{/etc/protocols}&\struct{protoent}&\func{getprotobyname}&
1035 \func{getprotobyaddr}\\
1038 \caption{Funzioni di risoluzione dei nomi per i vari servizi del
1039 \textit{Name Service Switch}.}
1040 \label{tab:name_resolution_functions}
1043 Delle funzioni di tab.~\ref{tab:name_resolution_functions} abbiamo trattato
1044 finora soltanto quelle relative alla risoluzione dei nomi, dato che sono le
1045 più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
1046 una entità esterna; per le altre invece, estensioni fornite dal NSS a parte,
1047 si fa sempre riferimento ai dati mantenuti nei rispettivi file.
1049 Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
1050 sui nomi dei servizi noti (cioè \texttt{http}, \texttt{smtp}, ecc.) da
1051 associare alle rispettive porte, le due funzioni da utilizzare per questo sono
1052 \funcd{getservbyname} e \funcd{getservbyaddr}, che permettono rispettivamente
1053 di ottenere il numero di porta associato ad un servizio dato il nome e
1054 viceversa; i loro prototipi sono:
1057 \funcdecl{struct servent *getservbyname(const char *name, const char *proto)}
1058 \funcdecl{struct servent *getservbyport(int port, const char *proto)}
1060 Risolvono il nome di un servizio nel rispettivo numero di porta e viceversa.
1062 \bodydesc{Ritornano il puntatore ad una struttura \struct{servent} con i
1063 risultati in caso di successo, o \const{NULL} in caso di errore.}
1066 Entrambe le funzioni prendono come ultimo argomento una stringa \param{proto}
1067 che indica il protocollo per il quale si intende effettuare la
1068 ricerca,\footnote{le informazioni mantenute in \file{/etc/services} infatti
1069 sono relative sia alle porte usate su UDP che su TCP, occorre quindi
1070 specificare a quale dei due protocolli si fa riferimento.} che nel caso si
1071 IP può avere come valori possibili solo \texttt{udp} o
1072 \texttt{tcp};\footnote{in teoria si potrebbe avere un qualunque protocollo fra
1073 quelli citati in \file{/etc/protocols}, posto che lo stesso supporti il
1074 concetto di \textsl{porta}, in pratica questi due sono gli unici presenti.}
1075 se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
1078 Il primo argomento è il nome del servizio per \func{getservbyname},
1079 specificato tramite la stringa \param{name}, mentre \func{getservbyport}
1080 richiede il numero di porta in \param{port}. Entrambe le funzioni eseguono una
1081 ricerca sul file \file{/etc/services}\footnote{il \textit{Name Service Switch}
1082 astrae il concetto a qualunque supporto su cui si possano mantenere i
1083 suddetti dati. } ed estraggono i dati dalla prima riga che corrisponde agli
1084 argomenti specificati; se la risoluzione ha successo viene restituito un
1085 puntatore ad una apposita struttura \struct{servent} contenente tutti i
1086 risultati), altrimenti viene restituito un puntatore nullo. Si tenga presente
1087 che anche in questo caso i dati vengono mantenuti in una area di memoria
1088 statica e che quindi la funzione non è rientrante.
1090 \begin{figure}[!htb]
1091 \footnotesize \centering
1092 \begin{minipage}[c]{15cm}
1093 \includestruct{listati/servent.h}
1095 \caption{La struttura \structd{servent} per la risoluzione dei nomi dei
1096 servizi e dei numeri di porta.}
1097 \label{fig:sock_servent_struct}
1100 La definizione della struttura \struct{servent} è riportata in
1101 fig.~\ref{fig:sock_servent_struct}, il primo campo, \var{s\_name} contiene
1102 sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
1103 ad un vettore di stringhe contenenti gli eventuali nomi alternativi
1104 utilizzabili per identificare lo stesso servizio. Infine \var{s\_port}
1105 contiene il numero di porta e \var{s\_proto} il nome del protocollo.
1107 Come riportato in tab.~\ref{tab:name_resolution_functions} ci sono analoghe
1108 funzioni per la risoluzione del nome dei protocolli e delle reti; non staremo
1109 a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
1110 comunque hanno una struttura del tutto analoga alle precedenti, e tutti i
1111 dettagli relativi al loro funzionamento possono essere trovati nelle
1112 rispettive pagine di manuale.
1114 Oltre alle funzioni di ricerca esistono delle ulteriori funzioni che prevedono
1115 una lettura sequenziale delle informazioni mantenute nel \textit{Name Service
1116 Switch} (in sostanza permettono di leggere i file contenenti le informazioni
1117 riga per riga), che sono analoghe a quelle elencate in
1118 tab.~\ref{tab:sys_passwd_func} per le informazioni relative ai dati degli
1119 utenti e dei gruppi. Nel caso specifico dei servizi avremo allora le tre
1120 funzioni \funcd{setservent}, \funcd{getservent} e \funcd{endservent} i cui
1124 \funcdecl{void setservent(int stayopen)}
1125 Apre il file \file{/etc/services} e si posiziona al suo inizio.
1127 \funcdecl{struct servent *getservent(void)}
1128 Legge la voce successiva nel file \file{/etc/services}.
1130 \funcdecl{void endservent(void)}
1131 Chiude il file \file{/etc/services}.
1133 \bodydesc{Le due funzioni \func{setservent} e \func{endservent} non
1134 restituiscono nulla, \func{getservent} restituisce il puntatore ad una
1135 struttura \struct{servent} in caso di successo e \const{NULL} in caso di
1136 errore o fine del file.}
1139 La prima funzione, \func{getservent}, legge una singola voce a partire dalla
1140 posizione corrente in \file{/etc/services}, pertanto si può eseguire una
1141 lettura sequenziale dello stesso invocandola più volte. Se il file non è
1142 aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
1143 voce. La seconda funzione, \func{setservent}, permette di aprire il file
1144 \file{/etc/services} per una successiva lettura, ma se il file è già stato
1145 aperto riporta la posizione di lettura alla prima voce del file, in questo
1146 modo si può far ricominciare da capo una lettura sequenziale. L'argomento
1147 \param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
1148 diverse chiamate a \func{getservbyname} e \func{getservbyaddr}.\footnote{di
1149 default dopo una chiamata a queste funzioni il file viene chiuso, cosicchè
1150 una successiva chiamata a \func{getservent} riparte dall'inizio.} La terza
1151 funzione, \funcd{endservent}, provvede semplicemente a chiudere il file.
1153 Queste tre funzioni per la lettura sequenziale di nuovo sono presenti per
1154 ciascuno dei vari tipi di informazione relative alle reti di
1155 tab.~\ref{tab:name_resolution_functions}; questo significa che esistono
1156 altrettante funzioni nella forma \texttt{setXXXent}, \texttt{getXXXent} e
1157 \texttt{endXXXent}, analoghe alle precedenti per la risoluzione dei servizi,
1158 che abbiamo riportato in tab.~\ref{tab:name_sequential_read}. Essendo, a
1159 parte il tipo di informazione che viene trattato, sostanzialmente identiche
1160 nel funzionamento e di scarso utilizzo, non staremo a trattarle una per una,
1161 rimandando alle rispettive pagine di manuale.
1166 \begin{tabular}[c]{|l|l|l|l|}
1168 \textbf{Informazione}&\multicolumn{3}{|c|}{\textbf{Funzioni}}\\
1171 indirizzo&\func{sethostent}&\func{gethostent}&\func{endhostent} \\
1172 servizio &cd te\func{setservent}&\func{getservent}&\func{endservent}\\
1173 rete &\func{setnetent}&\func{getnetent}&\func{endnetent}\\
1174 protocollo&\func{setprotoent}&\func{getprotoent}&\func{endprotoent}\\
1177 \caption{Funzioni lettura sequenziale dei dati del \textit{Name Service
1179 \label{tab:name_sequential_read}
1186 \subsection{Le funzioni avanzate per la risoluzione dei nomi}
1187 \label{sec:sock_advanced_name_services}
1189 Quelle illustrate nella sezione precedente sono le funzioni classiche per la
1190 risoluzione di nomi ed indirizzi IP, ma abbiamo già visto come esse soffrano
1191 di vari inconvenienti come il fatto che usano informazioni statiche, e non
1192 prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
1193 state create delle estensioni o metodi diversi che permettono di risolvere
1194 alcuni di questi inconvenienti,\footnote{rimane ad esempio il problema
1195 generico che si deve sapere in anticipo quale tipo di indirizzi IP (IPv4 o
1196 IPv6) corrispondono ad un certo nome a dominio.} comunque esse non
1197 forniscono una interfaccia sufficientemente generica.
1199 Inoltre in genere quando si ha a che fare con i socket non esiste soltanto il
1200 problema della risoluzione del nome che identifica la macchina, ma anche
1201 quello del servizio a cui ci si vuole rivolgere. Per questo motivo con lo
1202 standard POSIX 1003.1-2001 sono state indicate come deprecate le varie
1203 funzioni \func{gethostbyaddr}, \func{gethostbyname}, \var{getipnodebyname} e
1204 \var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
1207 La prima funzione di questa interfaccia è \funcd{getaddrinfo},\footnote{la
1208 funzione è definita, insieme a \func{getnameinfo} che vedremo più avanti,
1209 nell'\href{http://www.ietf.org/rfc/rfc2553.txt} {RFC~2553}.} che combina le
1210 funzionalità delle precedenti \func{getipnodebyname}, \func{getipnodebyaddr},
1211 \func{getservbyname} e \func{getservbyport}, consentendo di ottenere
1212 contemporaneamente sia la risoluzione di un indirizzo simbolico che del nome
1213 di un servizio; il suo prototipo è:
1216 \headdecl{sys/socket.h}
1219 \funcdecl{int getaddrinfo(const char *node, const char *service, const
1220 struct addrinfo *hints, struct addrinfo **res)}
1222 Esegue una risoluzione di un nome a dominio e di un nome di servizio.
1224 \bodydesc{La funzione restituisce 0 in caso di successo o un codice di
1225 errore diverso da zero in caso di fallimento.}
1228 La funzione prende come primo argomento il nome della macchina che si vuole
1229 risolvere, specificato tramite la stringa \param{node}. Questo argomento,
1230 oltre ad un comune nome a dominio, può indicare anche un indirizzo numerico in
1231 forma \textit{dotted-decimal} per IPv4 o in formato esadecimale per IPv6. Si
1232 può anche specificare il nome di una rete invece che di una singola macchina.
1233 Il secondo argomento, \param{service}, specifica invece il nome del servizio
1234 che si intende risolvere. Per uno dei due argomenti si può anche usare il
1235 valore \const{NULL}, nel qual caso la risoluzione verrà effettuata soltanto
1236 sulla base del valore dell'altro.
1238 Il terzo argomento, \param{hints}, deve essere invece un puntatore ad una
1239 struttura \struct{addrinfo} usata per dare dei \textsl{suggerimenti} al
1240 procedimento di risoluzione riguardo al protocollo o del tipo di socket che si
1241 intenderà utilizzare; \func{getaddrinfo} infatti permette di effettuare
1242 ricerche generiche sugli indirizzi, usando sia IPv4 che IPv6, e richiedere
1243 risoluzioni sui nomi dei servizi indipendentemente dal protocollo (ad esempio
1244 TCP o UDP) che questi possono utilizzare.
1246 \begin{figure}[!htb]
1247 \footnotesize \centering
1248 \begin{minipage}[c]{15cm}
1249 \includestruct{listati/addrinfo.h}
1251 \caption{La struttura \structd{addrinfo} usata nella nuova interfaccia POSIX
1252 per la risoluzione di nomi a dominio e servizi.}
1253 \label{fig:sock_addrinfo_struct}
1256 La struttura \struct{addrinfo}, la cui definizione\footnote{la definizione è
1257 ripresa direttamente dal file \texttt{netdb.h} in questa struttura viene
1258 dichiarata, la pagina di manuale riporta \type{size\_t} come tipo di dato
1259 per il campo \var{ai\_addrlen}, qui viene usata quanto previsto dallo
1260 standard POSIX, in cui viene utilizzato \type{socklen\_t}; i due tipi di
1261 dati sono comunque equivalenti.} è riportata in
1262 fig.~\ref{fig:sock_addrinfo_struct}, viene usata sia in ingresso, per passare
1263 dei valori di controllo alla funzione, che in uscita, per ricevere i
1264 risultati. Il primo campo, \var{ai\_flags}, è una maschera binaria di bit che
1265 permettono di controllare le varie modalità di risoluzione degli indirizzi,
1266 che viene usato soltanto in ingresso. I tre campi successivi \var{ai\_family},
1267 \var{ai\_socktype}, e \var{ai\_protocol} contengono rispettivamente la
1268 famiglia di indirizzi, il tipo di socket e il protocollo, in ingresso vengono
1269 usati per impostare una selezione (impostandone il valore nella struttura
1270 puntata da \param{hints}), mentre in uscita indicano il tipo di risultato
1271 contenuto nella struttura.
1273 Tutti i campi seguenti vengono usati soltanto in uscita; il campo
1274 \var{ai\_addrlen} indica la dimensione della struttura degli indirizzi
1275 ottenuta come risultato, il cui contenuto sarà memorizzato nella struttura
1276 \struct{sockaddr} posta all'indirizzo puntato dal campo \var{ai\_addr}. Il
1277 campo \var{ai\_canonname} è un puntatore alla stringa contenente il nome
1278 canonico della macchina, ed infine, quando la funzione restituisce più di un
1279 risultato, \var{ai\_next} è un puntatore alla successiva struttura
1280 \struct{addrinfo} della lista.
1282 Ovviamente non è necessario dare dei suggerimenti in ingresso, ed usando
1283 \const{NULL} come valore per l'argomento \param{hints} si possono compiere
1284 ricerche generiche. Se però si specifica un valore non nullo questo deve
1285 puntare ad una struttura \struct{addrinfo} precedentemente allocata nella
1286 quale siano stati opportunamente impostati i valori dei campi
1287 \var{ai\_family}, \var{ai\_socktype}, \var{ai\_protocol} ed \var{ai\_flags}.
1289 I due campi \var{ai\_family} e \var{ai\_socktype} prendono gli stessi valori
1290 degli analoghi argomenti della funzione \func{socket}; in particolare per
1291 \var{ai\_family} si possono usare i valori di tab.~\ref{tab:net_pf_names} ma
1292 sono presi in considerazione solo \const{PF\_INET} e \const{PF\_INET6}, mentre
1293 se non si vuole specificare nessuna famiglia di indirizzi si può usare il
1294 valore \const{PF\_UNSPEC}. Allo stesso modo per \var{ai\_socktype} si possono
1295 usare i valori illustrati in sez.~\ref{sec:sock_type} per indicare per quale
1296 tipo di socket si vuole risolvere il servizio indicato, anche se i soli
1297 significativi sono \const{SOCK\_STREAM} e \const{SOCK\_DGRAM}; in questo caso,
1298 se non si vuole effettuare nessuna risoluzione specifica, si potrà usare un
1301 Il campo \var{ai\_protocol} permette invece di effettuare la selezione dei
1302 risultati per il nome del servizio usando il numero identificativo del
1303 rispettivo protocollo di trasporto (i cui valori possibili sono riportati in
1304 \file{/etc/protocols}); di nuovo i due soli valori utilizzabili sono quelli
1305 relativi a UDP e TCP, o il valore nullo che indica di ignorare questo campo
1308 Infine l'ultimo campo è \var{ai\_flags}; che deve essere impostato come una
1309 maschera binaria; i bit di questa variabile infatti vengono usati per dare
1310 delle indicazioni sul tipo di risoluzione voluta, ed hanno valori analoghi a
1311 quelli visti in sez.~\ref{sec:sock_name_services} per \func{getipnodebyname};
1312 il valore di \var{ai\_flags} può essere impostata con un OR aritmetico delle
1313 costanti di tab.~\ref{tab:ai_flags_values}, ciascuna delle quali identifica un
1319 \begin{tabular}[c]{|l|p{10cm}|}
1321 \textbf{Costante} & \textbf{Significato} \\
1324 \const{AI\_PASSIVE} & viene utilizzato per ottenere un indirizzo in
1325 formato adatto per una successiva chiamata a
1326 \func{bind}. Se specificato quando si è usato
1327 \const{NULL} come valore per \param{node} gli
1328 indirizzi restituiti saranno inizializzati al
1329 valore generico (\const{INADDR\_ANY} per IPv4 e
1330 \const{IN6ADDR\_ANY\_INIT} per IPv6), altrimenti
1331 verrà usato l'indirizzo dell'interfaccia di
1332 \textit{loopback}. Se invece non è impostato gli
1333 indirizzi verrano restituiti in formato adatto ad
1334 una chiamata a \func{connect} o \func{sendto}.\\
1335 \const{AI\_CANONNAME} & richiede la restituzione del nome canonico della
1336 macchina, che verrà salvato in una stringa il cui
1337 indirizzo sarà restituito nel campo
1338 \var{ai\_canonname} della prima struttura
1339 \struct{addrinfo} dei risultati. Se il nome
1340 canonico non è disponibile al suo posto
1341 viene restituita una copia di \param{node}. \\
1342 \const{AI\_NUMERICHOST}& se impostato il nome della macchina specificato
1343 con \param{node} deve essere espresso in forma
1344 numerica, altrimenti sarà restituito un errore
1345 \const{EAI\_NONAME} (vedi
1346 tab.~\ref{tab:addrinfo_error_code}), in questo
1347 modo si evita ogni chiamata alle funzioni di
1349 \const{AI\_V4MAPPED} & stesso significato dell'analoga di
1350 tab.~\ref{tab:sock_getipnodebyname_flags}.\\
1351 \const{AI\_ALL} & stesso significato dell'analoga di
1352 tab.~\ref{tab:sock_getipnodebyname_flags}.\\
1353 \const{AI\_ADDRCONFIG} & stesso significato dell'analoga di
1354 tab.~\ref{tab:sock_getipnodebyname_flags}.\\
1357 \caption{Costanti associate ai bit del campo \var{ai\_flags} della struttura
1359 \label{tab:ai_flags_values}
1362 Come ultimo argomento di \func{getaddrinfo} deve essere passato un puntatore
1363 ad una variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che
1364 verrà utilizzata dalla funzione per riportare (come \textit{value result
1365 argument}) i propri risultati. La funzione infatti è rientrante, ed alloca
1366 autonomamente tutta la memoria necessaria in cui verranno riportati i
1367 risultati della risoluzione. La funzione scriverà in \param{res} il puntatore
1368 iniziale ad una \textit{linked list} di strutture di tipo \struct{addrinfo}
1369 contenenti tutte le informazioni ottenute.
1371 La funzione restituisce un valore nullo in caso di successo, o un codice in
1372 caso di errore. I valori usati come codice di errore sono riportati in
1373 tab.~\ref{tab:addrinfo_error_code}; dato che la funzione utilizza altre
1374 funzioni e chiamate al sistema per ottenere il suo risultato in generale il
1375 valore di \var{errno} non è significativo, eccetto il caso in cui si sia
1376 ricevuto un errore di \const{EAI\_SYSTEM}, nel qual caso l'errore
1377 corrispondente è riportato tramite \var{errno}.
1382 \begin{tabular}[c]{|l|p{10cm}|}
1384 \textbf{Costante} & \textbf{Significato} \\
1387 \const{EAI\_FAMILY} & la famiglia di indirizzi richiesta non è
1389 \const{EAI\_SOCKTYPE}& il tipo di socket richiesto non è supportato. \\
1390 \const{EAI\_BADFLAGS}& il campo \var{ai\_flags} contiene dei valori non
1392 \const{EAI\_NONAME} & il nome a dominio o il servizio non sono noti,
1393 viene usato questo errore anche quando si specifica
1394 il valore \const{NULL} per entrambi gli argomenti
1395 \param{node} e \param{service}. \\
1396 \const{EAI\_SERVICE} & il servizio richiesto non è disponibile per il tipo
1397 di socket richiesto, anche se può esistere per
1398 altri tipi di socket. \\
1399 \const{EAI\_ADDRFAMILY}& la rete richiesta non ha nessun indirizzo di rete
1400 per la famiglia di indirizzi specificata. \\
1401 \const{EAI\_NODATA} & la macchina specificata esiste, ma non ha nessun
1402 indirizzo di rete definito. \\
1403 \const{EAI\_MEMORY} & è stato impossibile allocare la memoria necessaria
1405 \const{EAI\_FAIL} & il DNS ha restituito un errore di risoluzione
1407 \const{EAI\_AGAIN} & il DNS ha restituito un errore di risoluzione
1408 temporaneo, si può ritentare in seguito. \\
1409 \const{EAI\_SYSTEM} & c'è stato un errore di sistema, si può controllare
1410 \var{errno} per i dettagli. \\
1412 % estensioni GNU, trovarne la documentazione
1413 % \const{EAI\_INPROGRESS}& richiesta in corso. \\
1414 % \const{EAI\_CANCELED}& la richiesta è stata cancellata.\\
1415 % \const{EAI\_NOTCANCELED}& la richiesta non è stata cancellata. \\
1416 % \const{EAI\_ALLDONE} & tutte le richieste sono complete. \\
1417 % \const{EAI\_INTR} & richiesta interrotta. \\
1420 \caption{Costanti associate ai valori dei codici di errore della funzione
1421 \func{getaddrinfo}.}
1422 \label{tab:addrinfo_error_code}
1425 Come per i codici di errore di \func{gethostbyname} anche in questo caso è
1426 fornita una apposita funzione, analoga di \func{strerror}, che consente di
1427 utilizzarli direttamente per stampare a video un messaggio esplicativo; la
1428 funzione è \func{gai\_strerror} ed il suo prototipo è:
1432 \funcdecl{const char *gai\_strerror(int errcode)}
1434 Fornisce il messaggio corrispondente ad un errore di \func{getaddrinfo}.
1436 \bodydesc{La funzione restituisce il puntatore alla stringa contenente il
1437 messaggio di errore.}
1440 La funzione restituisce un puntatore alla stringa contenente il messaggio
1441 corrispondente dal codice di errore \param{errcode} ottenuto come valore di
1442 ritorno di \func{getaddrinfo}. La stringa è allocata staticamente, ma essendo
1443 costante, ed accessibile in sola lettura, questo non comporta nessun problema
1444 di rientranza della funzione.
1446 Dato che ad un certo nome a dominio possono corrispondere più indirizzi IP
1447 (sia IPv4 che IPv6), e che un certo servizio può essere fornito su protocolli
1448 e tipi di socket diversi, in generale, a meno di non aver eseguito una
1449 selezione specifica attraverso l'uso di \param{hints}, si otterrà una diversa
1450 struttura \struct{addrinfo} per ciascuna possibilità. Ad esempio se si
1451 richiede la risoluzione del servizio \textit{echo} per l'indirizzo
1452 \texttt{www.truelite.it}, e si imposta \const{AI\_CANONNAME} per avere anche
1453 la risoluzione del nome canonico, si avrà come risposta della funzione la
1454 lista illustrata in fig.~\ref{fig:sock_addrinfo_list}.
1456 \begin{figure}[!htb]
1458 \includegraphics[width=10cm]{img/addrinfo_list}
1459 \caption{La \textit{linked list} delle strutture \struct{addrinfo}
1460 restituite da \func{getaddrinfo}.}
1461 \label{fig:sock_addrinfo_list}
1464 Come primo esempio di uso di \func{getaddrinfo} vediamo un programma
1465 elementare di interrogazione del resolver basato questa funzione, il cui corpo
1466 principale è riportato in fig.~\ref{fig:mygetaddr_example}. Il codice completo
1467 del programma, compresa la gestione delle opzioni in cui è gestita l'eventuale
1468 inizializzazione dell'argomento \var{hints} per restringere le ricerche su
1469 protocolli, tipi di socket o famiglie di indirizzi, è disponibile nel file
1470 \texttt{mygetaddr.c} dei sorgenti allegati alla guida.
1472 \begin{figure}[!htb]
1473 \footnotesize \centering
1474 \begin{minipage}[c]{15cm}
1475 \includecodesample{listati/mygetaddr.c}
1478 \caption{Esempio di codice per la risoluzione di un indirizzo.}
1479 \label{fig:mygetaddr_example}
1482 Il corpo principale inizia controllando (\texttt{\small 1--5}) il numero di
1483 argomenti passati, che devono essere sempre due, e corrispondere
1484 rispettivamente all'indirizzo ed al nome del servizio da risolvere. A questo
1485 segue la chiamata (\texttt{\small 7}) alla funzione \func{getaddrinfo}, ed il
1486 successivo controllo (\texttt{\small 8--11}) del suo corretto funzionamento,
1487 senza il quale si esce immediatamente stampando il relativo codice di errore.
1489 Se la funzione ha restituito un valore nullo il programma prosegue
1490 inizializzando (\texttt{\small 12}) il puntatore \var{ptr} che sarà usato nel
1491 sucessivo ciclo (\texttt{\small 14--35}) di scansione della lista delle
1492 strutture \struct{addrinfo} restituite dalla funzione. Prima di eseguire
1493 questa scansione (\texttt{\small 12}) viene stampato il valore del nome
1494 canonico che è presente solo nella prima struttura.
1496 La scansione viene ripetuta (\texttt{\small 14}) fintanto che si ha un
1497 puntatore valido. La selezione principale è fatta sul campo \var{ai\_family},
1498 che stabilisce a quale famiglia di indirizzi fa riferimento la struttura in
1499 esame. Le possibilità sono due, un indirizzo IPv4 o IPv6, se nessuna delle due
1500 si verifica si provvede (\texttt{\small 27--30}) a stampare un messaggio di
1501 errore ed uscire.\footnote{questa eventualità non dovrebbe mai verificarsi,
1502 almeno fintanto che la funzione \func{getaddrinfo} lavora correttamente.}
1504 Per ciascuno delle due possibili famiglie di indirizzi si estraggono le
1505 informazioni che poi verranno stampate alla fine del ciclo (\texttt{\small
1506 31--34}). Il primo caso esaminato (\texttt{\small 15--21}) è quello degli
1507 indirizzi IPv4, nel qual caso prima se ne stampa l'indentificazione
1508 (\texttt{\small 16}) poi si provvede a ricavare la struttura degli indirizzi
1509 (\texttt{\small 17}) indirizzata dal campo \var{ai\_addr}, eseguendo un
1510 opportuno casting del puntatore per poter estrarre da questa la porta
1511 (\texttt{\small 18}) e poi l'indirizzo (\texttt{\small 19}) che verrà
1512 convertito con una chiamata ad \func{inet\_ntop}.
1514 La stessa operazione (\texttt{\small 21--27}) viene ripetuta per gli indirizzi
1515 IPv6, usando la rispettiva struttura degli indirizzi. Si noti anche come in
1516 entrambi i casi per la chiamata a \func{inet\_ntop} si sia dovuto passare il
1517 puntatore al campo contenente l'indirizzo IP nella struttura puntata dal campo
1518 \var{ai\_addr}.\footnote{il meccanismo è complesso a causa del fatto che al
1519 contrario di IPv4, in cui l'indirizzo IP può essere espresso con un semplice
1520 numero intero, in IPv6 questo deve essere necessariamente fornito come
1521 struttura, e pertanto anche se nella struttura puntata da \var{ai\_addr}
1522 sono presenti direttamente i valori finali, per l'uso con \func{inet\_ntop}
1523 occorre comunque passare un puntatore agli stessi (ed il costrutto
1524 \code{\&addr6->sin6\_addr} è corretto in quanto l'operatore \texttt{->} ha
1525 on questo caso precedenza su \texttt{\&}).}
1527 Una volta estratte dalla struttura \struct{addrinfo} tutte le informazioni
1528 relative alla risoluzione richiesta e stampati i relativi valori, l'ultimo
1529 passo (\texttt{\small 34}) è di estrarre da \var{ai\_next} l'indirizzo della
1530 eventuale successiva struttura presente nella lista e ripetere il ciclo, fin
1531 tanto che, completata la scansione, questo avrà un valore nullo e si potrà
1532 terminare (\texttt{\small 36}) il programma.
1534 Si tenga presente che \func{getaddrinfo} non garantisce nessun particolare
1535 ordinamento della lista delle strutture \struct{addrinfo} restituite, anche se
1536 usualmente i vari indirizzi IP (se ne è presente più di uno) sono forniti
1537 nello stesso ordine in cui vengono inviati dal server DNS. In particolare
1538 nulla garantisce che vengano forniti prima i dati relativi ai servizi di un
1539 determinato protocollo o tipo di socket, se ne sono presenti di diversi. Se
1540 allora utilizziamo il nostro programma potremo verificare il risultato:
1542 [piccardi@gont sources]$ ./mygetaddr -c gapil.truelite.it echo
1543 Canonical name sources2.truelite.it
1545 Indirizzo 62.48.34.25
1549 Indirizzo 62.48.34.25
1555 Una volta estratti i risultati dalla \textit{linked list} puntata da
1556 \param{res} se questa non viene più utilizzata si dovrà avere cura di
1557 disallocare opportunamente tutta la memoria, per questo viene fornita
1558 l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
1562 \funcdecl{void freeaddrinfo(struct addrinfo *res)}
1564 Libera la memoria allocata da una precedente chiamata a \func{getaddrinfo}.
1566 \bodydesc{La funzione non restituisce nessun codice di errore.}
1569 La funzione prende come unico argomento il puntatore \param{res}, ottenuto da
1570 una precedente chiamata a \func{getaddrinfo}, e scandisce la lista delle
1571 strutture per liberare tutta la memoria allocata. Dato che la funzione non ha
1572 valori di ritorno deve essere posta molta cura nel passare un valore valido
1575 Si tenga presente infine che se si copiano i risultati da una delle strutture
1576 \struct{addrinfo} restituite nella lista indicizzata da \param{res}, occorre
1577 avere cura di eseguire una \index{\textit{deep~copy}}\textit{deep copy} in cui
1578 si copiano anche tutti i dati presenti agli indirizzi contenuti nella
1579 struttura \struct{addrinfo}, perché una volta disallocati i dati con
1580 \func{freeaddrinfo} questi non sarebbero più disponibili.
1582 Anche la nuova intefaccia definita da POSIX prevede una nuova funzione per
1583 eseguire la risoluzione inversa e determinare nomi di servizi e di dominio
1584 dati i rispettivi valori numerici. La funzione che sostituisce le varie
1585 \func{gethostbyname}, \func{geipnodebyname} e \func{getservname} è
1586 \funcd{getnameinfo}, ed il suo prototipo è:
1588 \headdecl{sys/socket.h}
1591 \funcdecl{int getnameinfo(const struct sockaddr *sa, socklen\_t salen, char
1592 *host, size\_t hostlen, char *serv, size\_t servlen, int flags)}
1594 Risolve il contenuto di una struttura degli indirizzi in maniera
1595 indipendente dal protocollo.
1597 \bodydesc{La funzione restituisce 0 in caso di successo e un codice di
1598 errore diverso da zero altrimenti.}
1601 La principale caratteristica di \func{getnameinfo} è che la funzione è in
1602 grado di eseguire una risoluzione inversa in maniera indipendente dal
1603 protocollo; il suo primo argomento \param{sa} infatti è il puntatore ad una
1604 struttura degli indirizzi generica, che può contenere sia indirizzi IPv4 che
1605 IPv6, la cui dimensione deve comunque essere specificata con l'argomento
1608 I risultati della funzione saranno restituiti nelle due stringhe puntate da
1609 \param{host} e \param{serv}, che dovranno essere state precedentemente
1610 allocate per una lunghezza massima che deve essere specificata con gli altri
1611 due argomenti \param{hostlen} e \param{servlen}. Si può, quando non si è
1612 interessati ad uno dei due, passare il valore \const{NULL} come argomento,
1613 così che la corrispondente informazione non verrà richiesta. Infine l'ultimo
1614 argomento \param{flags} è una maschera binaria i cui bit consentono di
1615 impostare le modalità con cui viene eseguita la ricerca, e deve essere
1616 specificato attraverso l'OR aritmetico dei valori illustrati in
1617 tab.~\ref{tab:getnameinfo_flags}.
1622 \begin{tabular}[c]{|l|p{10cm}|}
1624 \textbf{Costante} & \textbf{Significato} \\
1627 \const{NI\_NOFQDN} & richiede che venga restituita solo il nome della
1628 macchina all'interno del dominio al posto del
1629 nome completo (FQDN).\\
1630 \const{NI\_NUMERICHOST}& richiede che venga restituita la forma numerica
1631 dell'indirizzo (questo succede sempre se il nome
1632 non può essere ottenuto).\\
1633 \const{NI\_NAMEREQD} & richiede la restituzione di un errore se il nome
1634 non può essere risolto.\\
1635 \const{NI\_NUMERICSERV}& richiede che il servizio venga restituito in
1636 forma numerica (attraverso il numero di porta).\\
1637 \const{NI\_DGRAM} & richiede che venga restituito il nome del
1638 servizio su UDP invece che quello su TCP per quei
1639 pichi servizi (porte 512-214) che soni diversi
1640 nei due protocolli.\\
1643 \caption{Costanti associate ai bit dell'argomento \param{flags} della
1644 funzione \func{getnameinfo}.}
1645 \label{tab:getnameinfo_flags}
1648 La funzione ritorna zero in caso di successo, e scrive i propri risultati agli
1649 indirizzi indicati dagli argomenti \param{host} e \param{serv} come stringhe
1650 terminate dal carattere NUL, a meno che queste non debbano essere troncate
1651 qualora la loro dimensione ecceda quelle specificate dagli argomenti
1652 \param{hostlen} e \param{servlen}. Sono comunque definite le due costanti
1653 \const{NI\_MAXHOST} e \const{NI\_MAXSERV}\footnote{in Linux le due costanti
1654 sono definite in \file{netdb.h} ed hanno rispettivamente il valore 1024 e
1655 12.} che possono essere utilizzate come limiti massimi. In caso di errore
1656 viene restituito invece un codice che assume gli stessi valori illustrati in
1657 tab.~\ref{tab:addrinfo_error_code}.
1659 A questo punto possiamo fornire degli esempi di utilizzo della nuova
1660 interfaccia, adottandola per le precedenti implementazioni del client e del
1661 server per il servizio \textit{echo}; dato che l'uso delle funzioni appena
1662 illustrate (in particolare di \func{getaddrinfo}) è piuttosto complesso,
1663 essendo necessaria anche una impostazione diretta dei campi dell'argomento
1664 \param{hints}, provvederemo una interfaccia semplificata per i due casi visti
1665 finora, quello in cui si specifica nel client un indirizzo remoto per la
1666 connessione al server, e quello in cui si specifica nel server un indirizzo
1667 locale su cui porsi in ascolto.
1669 La prima funzione della nostra intefaccia semplificata è \func{sockconn} che
1670 permette di ottenere un socket, connesso all'indirizzo ed al servizio
1671 specificati. Il corpo della funzione è riportato in
1672 fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
1673 dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
1676 \begin{figure}[!htb]
1677 \footnotesize \centering
1678 \begin{minipage}[c]{15cm}
1679 \includecodesample{listati/sockconn.c}
1682 \caption{Il codice della funzione \func{sockconn}.}
1683 \label{fig:sockconn_code}
1686 La funzione prende quattro argomenti, i primi due sono le stringhe che
1687 indicano il nome della macchina a cui collegarsi ed il relativo servizio su
1688 cui sarà effettuata la risoluzione; seguono il protocollo da usare (da
1689 specificare con il valore numerico di \file{/etc/protocols}) ed il tipo di
1690 socket (al solito specificato con i valori illustrati in
1691 sez.~\ref{sec:sock_type}). La funzione ritorna il valore del file descriptor
1692 associato al socket (un numero positivo) in caso di successo, o -1 in caso di
1693 errore; per risolvere il problema di non poter passare indietro i valori di
1694 ritorno di \func{getaddrinfo} contenenti i relativi codici di
1695 errore\footnote{non si può avere nessuna certezza che detti valori siano
1696 negativi, è questo è invece nessario per evitare ogni possibile ambiguità
1697 nei confronti del valore di ritorno in caso di successo.} si sono stampati i
1698 messaggi d'errore direttamente nella funzione.
1700 Una volta definite le variabili necessarie (\texttt{\small 3--5}) la funzione
1701 prima (\texttt{\small 6}) azzera il contenuto della struttura \var{hint} e poi
1702 provvede (\texttt{\small 7--9}) ad inizializzarne i valori necessari per la
1703 chiamata (\texttt{\small 10}) a \func{getaddrinfo}. Di quest'ultima si
1704 controlla (\texttt{\small 12-16}) il codice di ritorno, in modo da stampare un
1705 avviso di errore, azzerare \var{errno} ed uscire in caso di errore. Dato che
1706 ad una macchina possono corrispondere più indirizzi IP, e di tipo diverso (sia
1707 IPv4 che IPv6), mantre il servizio può essere in ascolto soltanto su uno solo
1708 di questi, si provvede a tentare la connessione per ciascun indirizzo
1709 restituito all'interno di un ciclo (\texttt{\small 18-40}) di scansione della
1710 lista restituita da \func{getaddrinfo}, ma prima (\texttt{\small 17}) si salva
1711 il valore del puntatore per poterlo riutilizzare alla fine per disallocare la
1714 Il ciclo viene ripetuto (\texttt{\small 18}) fintanto che si hanno indirizzi
1715 validi, ed inizia (\texttt{\small 19}) con l'apertura del socket; se questa
1716 fallisce si controlla (\texttt{\small 20}) se sono disponibili altri
1717 indirizzi, nel qual caso si passa al successivo (\texttt{\small 21}) e si
1718 riprende (\texttt{\small 22}) il ciclo da capo; se non ve ne sono si stampa
1719 l'errore ritornando immediatamente (\texttt{\small 24-27}). Quando la
1720 creazione del socket ha avuto successo si procede (\texttt{\small 29})
1721 direttamente con la connessione, di nuovo in caso di fallimento viene ripetuto
1722 (\texttt{\small 30--38}) il controllo se vi sono o no altri indirizzi da
1723 provare nella stessa modalità fatta in precedenza, aggiungendovi però in
1724 entrambi i casi (\texttt{\small 32} e (\texttt{\small 36}) la chiusura del
1725 socket precedentemente aperto, che non è più utilizzabile.
1727 Se la connessione ha avuto successo invece si termina (\texttt{\small 39})
1728 direttamente il ciclo, e prima di ritornare (\texttt{\small 31}) il valore del
1729 file descriptor del socket si provvede (\texttt{\small 30}) a liberare le
1730 strutture \struct{addrinfo} allocate da \func{getaddrinfo} utilizzando il
1731 valore del relativo puntatore precedentemente (\texttt{\small 17}) salvato.
1732 Si noti come per la funzione sia del tutto irrilevante se la struttura
1733 ritornata contiene indirizzi IPv6 o IPv4, in quanto si fa uso direttamente dei
1734 dati relativi alle strutture degli indirizzi di \struct{addrinfo} che sono
1735 \textsl{opachi} rispetto all'uso della funzione \func{connect}.
1737 \begin{figure}[!htb]
1738 \footnotesize \centering
1739 \begin{minipage}[c]{15cm}
1740 \includecodesample{listati/TCP_echo_fifth.c}
1743 \caption{Il nuovo codice per la connessione del client \textit{echo}.}
1744 \label{fig:TCP_echo_fifth}
1747 Per usare questa funzione possiamo allora modificare ulteriormente il nostro
1748 programma client per il servizio \textit{echo}; in questo caso rispetto al
1749 codice usato finora per collegarsi (vedi fig.~\ref{fig:TCP_echo_client_1})
1750 avremo una semplificazione per cui il corpo principale del nostro client
1751 diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
1752 chiamate a \func{socket}, \func{inet\_pton} e \func{connect} sono sostituite
1753 da una singola chiamata a \func{sockconn}. Inoltre il nuovo client (il cui
1754 codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
1755 consente di utilizzare come argomento del programma un nome a dominio al posto
1756 dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
1758 \begin{figure}[!htb]
1759 \footnotesize \centering
1760 \begin{minipage}[c]{15cm}
1761 \includecodesample{listati/sockbind.c}
1764 \caption{Il codice della funzione \func{sockbind}.}
1765 \label{fig:sockbind_code}
1768 La seconda funzione di ausilio è \func{sockbind}, il cui corpo principale è
1769 riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
1770 nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
1771 notare la funzione è del tutto analoga alla precedente \func{sockconn}, e
1772 prende gli stessi argomenti, però invece di eseguire una connessione con
1773 \func{connect} si limita a chiamare \func{bind} per collegare il socket ad una
1776 Dato che la funzione è pensata per essere utilizzata da un server ci si può
1777 chiedere a quale scopo mantenere l'argomento \param{host} quando l'indirizzo
1778 di questo è usualmente noto. Si ricordi però quanto detto in
1779 sez.~\ref{sec:TCP_func_bind}, relativamente al significato della scelta di un
1780 indirizzo specifico come argomento di \func{bind}, che consente di porre il
1781 server in ascolto su uno solo dei possibili diversi indirizzi presenti su di
1782 una macchina. Se non si vuole che la funzione esegua \func{bind} su un
1783 indirizzo specifico, ma utilizzi l'indirizzo generico, occorrerà avere cura di
1784 passare un valore \const{NULL} come valore per l'argomento \var{host}; l'uso
1785 del valore \const{AI\_PASSIVE} serve ad ottenere il valore generico nella
1786 rispettiva struttura degli indirizzi.
1788 Come già detto la funzione è analoga a \func{sockconn} ed inizia azzerando ed
1789 inizializzando (\texttt{\small 6-11}) opportunamente la struttura \var{hint}
1790 con i valori ricevuti come argomenti, soltanto che in questo caso si è usata
1791 (\texttt{\small 8}) una impostazione specifica dei flag di \var{hint} usando
1792 \const{AI\_PASSIVE} per indicare che il socket sarà usato per una apertura
1793 passiva. Per il resto la chiamata (\texttt{\small 12-18}) a \func{getaddrinfo}
1794 e ed il ciclo principale (\texttt{\small 20--42}) sono identici, solo che si è
1795 sostituita (\texttt{\small 31}) la chiamata a \func{connect} con una chiamata
1796 a \func{bind}. Anche la conclusione (\texttt{\small 43--44}) della funzione è
1799 Si noti come anche in questo caso si siano inserite le stampe degli errori
1800 sullo standard error, nonostante la funzione possa essere invocata da un
1801 demone. Nel nostro caso questo non è un problema in quanto se la funzione non
1802 ha successo il programma deve uscire immediatamente prima di essere posto in
1803 background, e può quindi scrivere gli errori direttamente sullo standard
1806 \begin{figure}[!htb]
1807 \footnotesize \centering
1808 \begin{minipage}[c]{15cm}
1809 \includecodesample{listati/TCP_echod_third.c}
1812 \caption{Nuovo codice per l'apertura passiva del server \textit{echo}.}
1813 \label{fig:TCP_echod_third}
1816 Con l'uso di questa funzione si può modificare anche il codice del nostro
1817 server \textit{echo}, che rispetto a quanto illustrato nella versione iniziale
1818 di fig.~\ref{fig:TCP_echo_server_first_code} viene modificato nella forma
1819 riportata in fig.~\ref{fig:TCP_echod_third}. In questo caso il socket su cui
1820 porsi in ascolto viene ottenuto (\texttt{\small 15--18}) da \func{sockbind}
1821 che si cura anche della eventuale risoluzione di un indirizzo specifico sul
1822 quale si voglia far ascoltare il server.
1826 \section{Le opzioni dei socket}
1827 \label{sec:sock_options}
1829 Benché dal punto di vista del loro uso come canali di trasmissione di dati i
1830 socket siano trattati allo stesso modo dei file, ed acceduti tramite i file
1831 descriptor, la normale interfaccia usata per la gestione dei file non è
1832 sufficiente a poterne controllare tutte le caratteristiche, che variano tra
1833 l'altro a seconda del loro tipo (e della relativa forma di comunicazione
1834 sottostante). In questa sezione vedremo allora quali sono le funzioni dedicate
1835 alla gestione delle caratteristiche specifiche dei vari tipi di socket, le
1836 cosiddette \textit{socket options}.
1839 \subsection{Le funzioni \func{setsockopt} e \func{getsockopt}}
1840 \label{sec:sock_setsockopt}
1842 Le varie caratteristiche dei socket possono essere gestite attraverso l'uso di
1843 due funzioni generiche che permettono rispettivamente di impostarle e di
1844 recuperarne il valore corrente. La prima di queste due funzioni, quella usata
1845 per impostare le \textit{socket options}, è \funcd{setsockopt}, ed il suo
1848 \headdecl{sys/socket.h}
1849 \headdecl{sys/types.h}
1851 \funcdecl{int setsockopt(int sock, int level, int optname, const void
1852 *optval, socklen\_t optlen)}
1855 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1856 errore, nel qual caso \var{errno} assumerà i valori:
1858 \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
1859 \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
1860 \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
1861 \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
1863 \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
1869 Il primo argomento della funzione, \param{sock}, indica il socket su cui si
1870 intende operare; il secondo argomento, \param{level} indica invece il livello
1871 a cui si intende impostare l'opzione. Come abbiamo visto in
1872 sez.~\ref{sec:net_protocols} infatti i protocolli di rete sono strutturati su
1873 più livelli; pertanto anche le proprietà e le opzioni disponibili dipendono
1874 dai protocolli usati dal socket sul quale si va ad agire, e saranno anche esse
1875 differenziate a seconda del protocollo cui fanno riferimento.
1880 Il valore di \param{level} seleziona allora il livello sul quale si va ad
1881 intervenire e permette di usare le opzioni definite su quel livello. Esiste
1882 poi il valore \const{SOL\_SOCKET} che indica un livello generico e cioè le
1883 opzioni disponibili per qualunque tipo di socket. Per impostare le opzioni
1884 relative alle funzionalità disponibili per socket che usano particolari
1885 protocolli può utilizzare il valore numerico che identifica questi ultimi in
1886 \file{/etc/protocols}, ma più comunemente si suano le apposite costanti
1887 \texttt{SOL\_*} riportate in tab.~\ref{tab:sock_option_levels} dove si sono
1888 riassunti i possibili valori per l'argomento \param{level}.\footnote{la
1889 notazione in questo caso è, purtroppo, abbastanza confusa: infatti in Linux
1890 il valore si può impostare sia usando le costanti \texttt{SOL\_*}, che delle
1891 analoghe \texttt{IPPROTO\_*} (citate anche da Stevens in \cite{UNP1}) che di
1892 nuovo sono equivalenti ai numeri di protocollo di \file{/etc/protocols}; con
1893 una eccesione specifica, che è quella del protocollo ICMP, per la quale non
1894 esista una costante, dato poi che il suo valore, 1, è anche quello che viene
1895 assegnato a \const{SOL\_SOCKET}.}
1900 \begin{tabular}[c]{|l|l|}
1902 \textbf{Livello} & \textbf{Significato} \\
1905 \const{SOL\_SOCKET}& opzioni generiche dei socket.\\
1906 \const{SOL\_IP} & opzioni specifiche per i socket che usano IPv4.\\
1907 \const{SOL\_TCP} & opzioni per i socket che usano TCP.\\
1908 \const{SOL\_IPV6} & opzioni specifiche per i socket che usano IPv6.\\
1909 \const{SOL\_ICMPV6}& opzioni specifiche per i socket che usano ICMPv6.\\
1912 \caption{Possibili valori dell'argomento \param{level} delle
1913 funzioni \func{setsockopt} e \func{getsockopt}.}
1914 \label{tab:sock_option_levels}
1919 \subsection{Le opzioni generiche}
1920 \label{sec:sock_generic_options}
1922 Anche se ciascun tipo di socket presenta una serie di caratteristiche
1923 particolari, gestite attraverso delle opzioni specifiche, ma esiste un insieme
1924 generico di opzioni che possono applicarsi a qualunque tipo di socket.
1927 \section{Altre funzioni di controllo}
1928 \label{sec:sock_ctrl_func}
1930 Benché la maggior parte delle caratteristiche dei socket sia gestita
1931 attraverso le due funzioni \func{setsockopt} e \func{getsockopt}, alcune
1932 funzionalità possono essere impostate attraverso quelle che sono le funzioni
1933 classiche per il controllo delle proprietà dei file, cioè \func{fcntl} e
1937 \subsection{L'uso di \func{fcntl} per i socket}
1938 \label{sec:sock_fcntl}
1940 Abbiamo già trattato l'uso di \func{fcntl} in sez.~\ref{sec:file_fcntl}, dove
1941 però ne abbiamo descritto le funzionalità nell'ambito della sua applicazione a
1942 file descriptor associati a file normali; tratteremo qui invece il suo uso
1943 specifico quando la si impiega su file descriptor associati a dei socket.
1946 \subsection{L'uso di \func{ioctl} per i socket}
1947 \label{sec:sock_ioctl}
1949 Come per \func{fcntl} abbiamo trattato l'uso di \func{ioctl} in
1950 sez.~\ref{sec:file_ioctl}, dove ne abbiamo descritto le funzionalità
1951 nell'ambito dell'applicazione su file normali; tratteremo qui il suo uso
1952 specifico quando la si impiega su file descriptor associati a dei socket.
1955 \subsection{L'uso di \func{sysctl} per le proprietà della rete}
1956 \label{sec:sock_sysctl}
1958 Come ultimo argomento di questa sezione tratteremo l'uso della funzione
1959 \func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
1960 sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
1961 impostazioni relative a proprietà generali dei socket (di tutti quelli di un
1962 certo tipo o di tutti quelli che usano un certo protocollo) rispetto alle
1963 funzioni viste finora che consentono di controllare quelle di un singolo
1969 %%% Local Variables:
1971 %%% TeX-master: "gapil"