3 %% Copyright (C) 2004-2017 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
12 \chapter{La gestione dei socket}
13 \label{cha:sock_generic_management}
15 Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
16 alla gestione dei socket, come la gestione della risoluzione di nomi e
17 indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
18 socket, e le funzioni di controllo che permettono di modificarne il
22 \section{La risoluzione dei nomi}
23 \label{sec:sock_name_resolution}
25 Negli esempi dei capitoli precedenti abbiamo sempre identificato le singole
26 macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
27 conversione elementare illustrate in sez.~\ref{sec:sock_addr_func} che
28 permettono di passare da un indirizzo espresso in forma \textit{dotted
29 decimal} ad un numero. Vedremo in questa sezione le funzioni utilizzate per
30 poter utilizzare dei nomi simbolici al posto dei valori numerici, e viceversa
31 quelle che permettono di ottenere i nomi simbolici associati ad indirizzi,
32 porte o altre proprietà del sistema.
35 \subsection{La struttura del \textit{resolver}}
36 \label{sec:sock_resolver}
38 \itindbeg{resolver} La risoluzione dei nomi è associata tradizionalmente al
39 servizio del \itindex{Domain~Name~Service} \textit{Domain Name Service} che
40 permette di identificare le macchine su internet invece che per numero IP
41 attraverso il relativo \textsl{nome a dominio}.\footnote{non staremo ad
42 entrare nei dettagli della definizione di cosa è un nome a dominio, dandolo
43 per noto, una introduzione alla problematica si trova in \cite{AGL} (cap.~9)
44 mentre per una trattazione approfondita di tutte le problematiche relative
45 al DNS si può fare riferimento a \cite{DNSbind}.} In realtà per DNS si
46 intendono spesso i server che forniscono su internet questo servizio, mentre
47 nel nostro caso affronteremo la problematica dal lato client, di un qualunque
48 programma che necessita di compiere questa operazione.
51 \centering \includegraphics[width=11cm]{img/resolver}
52 \caption{Schema di funzionamento delle funzioni 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 funzioni 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
86 \conffile{/etc/hosts}.
88 Per questo aspetto il file di configurazione principale del sistema è
89 \conffile{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi
90 IP dei server DNS da contattare; a questo si affiancava (fino alle \acr{glibc}
91 2.4) il file \conffile{/etc/host.conf} il cui scopo principale era indicare
92 l'ordine in cui eseguire la risoluzione dei nomi (se usare prima i valori di
93 \conffile{/etc/hosts} o quelli del DNS). Tralasciamo i dettagli relativi alle
94 varie direttive che possono essere usate in questi file, che si trovano nelle
95 rispettive pagine di manuale.
97 Con il tempo però è divenuto possibile fornire diversi sostituti per
98 l'utilizzo delle associazione statiche in \conffile{/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 \conffile{/etc/protocols} e \conffile{/etc/services}.
110 Molte di queste informazioni non si trovano su un DNS, ma in una rete locale
111 può essere molto utile centralizzare il mantenimento di alcune di esse su
112 opportuni server. Inoltre l'uso di diversi supporti possibili per le stesse
113 informazioni (ad esempio il nome delle macchine può essere mantenuto sia
114 tramite \conffile{/etc/hosts}, che con il DNS, che con NIS) comporta il
115 problema dell'ordine in cui questi vengono interrogati. Con le implementazioni
116 classiche i vari supporti erano introdotti modificando direttamente le
117 funzioni di libreria, prevedendo un ordine di interrogazione predefinito e non
118 modificabile (a meno di una ricompilazione delle librerie stesse).
120 \itindbeg{Name~Service~Switch~(NSS)}
122 Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
123 eseguità dal \textit{resolver} è stata inclusa all'interno di un meccanismo
124 generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
125 associate chiamato \textit{Name Service Switch}, cui abbiamo accennato anche in
126 sez.~\ref{sec:sys_user_group} per quanto riguarda la gestione dei dati
127 associati a utenti e gruppi. Il sistema è stato introdotto la prima volta
128 nelle librerie standard di Solaris e le \acr{glibc} hanno ripreso lo stesso
129 schema; si tenga presente che questo sistema non esiste per altre librerie
130 standard come le \acr{libc5} o le \acr{uclib}.
132 Il \textit{Name Service Switch} (cui spesso si fa riferimento con l'acronimo
133 NSS) è un sistema di librerie dinamiche che permette di definire in maniera
134 generica sia i supporti su cui mantenere i dati di corrispondenza fra nomi e
135 valori numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti
136 disponibili. Il sistema prevede una serie di possibili classi di
137 corrispondenza, quelle attualmente definite sono riportate in
138 tab.~\ref{tab:sys_NSS_classes}.
143 \begin{tabular}[c]{|l|p{8cm}|}
145 \textbf{Classe} & \textbf{Tipo di corrispondenza}\\
148 \texttt{passwd} & Corrispondenze fra nome dell'utente e relative
149 proprietà (\ids{UID}, gruppo principale, ecc.).\\
150 \texttt{shadow} & Corrispondenze fra username e password dell'utente
151 (e altre informazioni relative alle password).\\
152 \texttt{group} & Corrispondenze fra nome del gruppo e proprietà dello
154 \texttt{aliases} & Alias per la posta elettronica.\\
155 \texttt{ethers} & Corrispondenze fra numero IP e MAC address della
157 \texttt{hosts} & Corrispondenze fra nome a dominio e numero IP.\\
158 \texttt{netgroup} & Corrispondenze fra gruppo di rete e macchine che lo
160 \texttt{networks} & Corrispondenze fra nome di una rete e suo indirizzo
162 \texttt{protocols}& Corrispondenze fra nome di un protocollo e relativo
163 numero identificativo.\\
164 \texttt{rpc} & Corrispondenze fra nome di un servizio RPC e relativo
165 numero identificativo.\\
166 \texttt{publickey}& Chiavi pubbliche e private usate per gli RFC sicuri,
167 utilizzate da NFS e NIS+. \\
168 \texttt{services} & Corrispondenze fra nome di un servizio e numero di
172 \caption{Le diverse classi di corrispondenze definite
173 all'interno del \textit{Name Service Switch}.}
174 \label{tab:sys_NSS_classes}
177 % TODO rivedere meglio la tabella
179 Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
180 file \conffile{/etc/nsswitch.conf}; questo contiene una riga di configurazione
181 per ciascuna di queste classi, che viene inizia col nome di
182 tab.~\ref{tab:sys_NSS_classes} seguito da un carattere ``\texttt{:}'' e
183 prosegue con la lista dei \textsl{servizi} su cui le relative informazioni
184 sono raggiungibili, scritti nell'ordine in cui si vuole siano interrogati.
185 Pertanto nelle versioni recenti delle librerie è questo file e non
186 \conffile{/etc/host.conf} a indicare l'ordine con cui si esegue la
187 risoluzione dei nomi.
189 Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
190 \texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che
191 realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
192 nome utilizzato dentro \conffile{/etc/nsswitch.conf}, dovrà essere presente
193 (usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
194 implementa le funzioni.
196 In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
197 su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
198 fornite dal sistema del \textit{Name Service Switch}, dal punto di vista di un
199 programma che deve effettuare la risoluzione di un nome a dominio, tutto
200 quello che conta sono le funzioni classiche che il \textit{resolver} mette a
201 disposizione (è cura delle \acr{glibc} tenere conto della presenza del
202 \textit{Name Service Switch}) e sono queste quelle che tratteremo nelle
205 \itindend{Name~Service~Switch~(NSS)}
208 \subsection{Le funzioni di interrogazione del DNS}
209 \label{sec:sock_resolver_functions}
211 Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
212 dominio conviene trattare in maniera più dettagliata il servizio DNS. Come
213 accennato questo, benché esso in teoria sia solo uno dei possibili supporti su
214 cui mantenere le informazioni, in pratica costituisce il meccanismo principale
215 con cui vengono risolti i nomi a dominio. Inolte esso può fornire anche
216 ulteriori informazioni oltre relative alla risoluzione dei nomi a dominio.
217 Per questo motivo esistono una serie di funzioni di libreria che servono
218 specificamente ad eseguire delle interrogazioni verso un server DNS, funzioni
219 che poi vengono utilizzate anche per realizzare le funzioni generiche di
220 libreria usate dal sistema del \textit{resolver}.
222 Il sistema del DNS è in sostanza di un database distribuito organizzato in
223 maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno
224 dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a
225 dominio sono organizzati in una struttura ad albero analoga a quella
226 dell'albero dei file, con domini di primo livello (come i \texttt{.org}),
227 secondo livello (come \texttt{.truelite.it}), ecc. In questo caso le
228 separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}''
229 ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si
230 stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
231 ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
232 genere non viene mai scritto esplicitamente, ma che, come chiunque abbia
233 configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
234 \textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo
235 funziona con il criterio della \textsl{delegazione}, un server responsabile
236 per un dominio di primo livello può delegare la risoluzione degli indirizzi
237 per un suo dominio di secondo livello ad un altro server, il quale a sua volta
238 potrà delegare la risoluzione di un eventuale sotto-dominio di terzo livello ad
239 un altro server ancora.
241 Come accennato un server DNS è in grado di fare molto altro rispetto alla
242 risoluzione di un nome a dominio in un indirizzo IP: ciascuna voce nel
243 database viene chiamata \textit{resource record}, e può contenere diverse
244 informazioni. In genere i \textit{resource record} vengono classificati per la
245 \textsl{classe di indirizzi} cui i dati contenuti fanno riferimento, e per il
246 \textsl{tipo} di questi ultimi (ritroveremo classi di indirizzi e tipi di
247 record più avanti in tab.~\ref{tab:DNS_address_class} e
248 tab.~\ref{tab:DNS_record_type}). Oggigiorno i dati mantenuti nei server DNS
249 sono quasi esclusivamente relativi ad indirizzi internet, per cui in pratica
250 viene utilizzata soltanto una classe di indirizzi; invece le corrispondenze
251 fra un nome a dominio ed un indirizzo IP sono solo uno fra i vari tipi di
252 informazione che un server DNS fornisce normalmente.
254 L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
255 \textit{resolver} prevede, oltre a quelle relative alla semplice risoluzione
256 dei nomi, un insieme di funzioni specifiche dedicate all'interrogazione di un
257 server DNS, tutte nella forma \texttt{res\_}\textsl{\texttt{nome}}. La prima
258 di queste funzioni è \funcd{res\_init}, il cui prototipo è:
262 \fhead{arpa/nameser.h}
264 \fdecl{int res\_init(void)}
265 \fdesc{Inizializza il sistema del \textit{resolver}.}
267 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore.
271 La funzione legge il contenuto dei file di configurazione per impostare il
272 dominio di default, gli indirizzi dei server DNS da contattare e l'ordine
273 delle ricerche; se non sono specificati server verrà utilizzato l'indirizzo
274 locale, e se non è definito un dominio di default sarà usato quello associato
275 con l'indirizzo locale (ma questo può essere sovrascritto con l'uso della
276 variabile di ambiente \envvar{LOCALDOMAIN}). In genere non è necessario
277 eseguire questa funzione esplicitamente, in quanto viene automaticamente
278 chiamata la prima volta che si esegue una qualunque delle altre.
280 Le impostazioni e lo stato del \textit{resolver} inizializzati da
281 \func{res\_init} vengono mantenuti in una serie di variabili raggruppate nei
282 campi di una apposita struttura. Questa struttura viene definita in
283 \headfiled{resolv.h} e mantenuta nella variabile globale \var{\_res}, che
284 viene utilizzata internamente da tutte le funzioni dell'interfaccia. Questo
285 consente anche di accedere direttamente al contenuto della variabile
286 all'interno di un qualunque programma, una volta che la sia opportunamente
288 \includecodesnip{listati/resolv_option.c}
290 Dato che l'uso di una variabile globale rende tutte le funzioni
291 dell'interfaccia classica non rientranti, queste sono state deprecate in
292 favore di una nuova interfaccia in cui esse sono state sostituite da
293 altrettante nuove funzioni, il cui nome è ottenuto apponendo una
294 ``\texttt{n}'' al nome di quella tradizionale (cioè nella forma
295 \texttt{res\_n\textsl{nome}}). Tutte le nuove funzioni sono identiche alle
296 precedenti, ma hanno un primo argomento aggiuntivo, \param{statep}, puntatore
297 ad una struttura dello stesso tipo di \var{\_res}. Questo consente di usare
298 una variabile locale per mantenere lo stato del \textit{resolver}, rendendo le
299 nuove funzioni rientranti. In questo caso per poter utilizzare il nuovo
300 argomento occorrerà una opportuna dichiarazione del relativo tipo di dato con:
301 \includecodesnip{listati/resolv_newoption.c}
303 Così la nuova funzione utilizzata per inizializzare il \textit{resolver} (che
304 come la precedente viene chiamata automaticamente da tutte altre funzioni) è
305 \funcd{res\_ninit}, ed il suo prototipo è:
309 \fhead{arpa/nameser.h}
311 \fdecl{int res\_ninit(res\_state statep)}
312 \fdesc{Inizializza il sistema del \textit{resolver}.}
314 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore.
318 Indipendentemente da quale versione delle funzioni si usino, tutti i campi
319 della struttura (\var{\_res} o la variabile puntata da \param{statep}) sono ad
320 uso interno, e vengono usualmente inizializzate da \func{res\_init} o
321 \func{res\_ninit} in base al contenuto dei file di configurazione e ad una
322 serie di valori di default. L'unico campo che può essere utile modificare è
323 \var{\_res.options} (o l'equivalente della variabile puntata
324 da\param{statep}), una maschera binaria che contiene una serie di bit che
325 esprimono le opzioni che permettono di controllare il comportamento del
331 \begin{tabular}[c]{|l|p{8cm}|}
333 \textbf{Costante} & \textbf{Significato} \\
336 \constd{RES\_INIT} & Viene attivato se è stata chiamata
338 \constd{RES\_DEBUG} & Stampa dei messaggi di debug.\\
339 \constd{RES\_AAONLY} & Accetta solo risposte autoritative.\\
340 \constd{RES\_USEVC} & Usa connessioni TCP per contattare i server
341 invece che l'usuale UDP.\\
342 \constd{RES\_PRIMARY} & Interroga soltanto server DNS primari.\\
343 \constd{RES\_IGNTC} & Ignora gli errori di troncamento, non ritenta la
344 richiesta con una connessione TCP.\\
345 \constd{RES\_RECURSE} & Imposta il bit che indica che si desidera
346 eseguire una interrogazione ricorsiva.\\
347 \constd{RES\_DEFNAMES} & Se attivo \func{res\_search} aggiunge il nome
348 del dominio di default ai nomi singoli (che non
349 contengono cioè un ``\texttt{.}'').\\
350 \constd{RES\_STAYOPEN} & Usato con \const{RES\_USEVC} per mantenere
351 aperte le connessioni TCP fra interrogazioni
353 \constd{RES\_DNSRCH} & Se attivo \func{res\_search} esegue le ricerche
354 di nomi di macchine nel dominio corrente o nei
355 domini ad esso sovrastanti.\\
356 \constd{RES\_INSECURE1} & Blocca i controlli di sicurezza di tipo 1.\\
357 \constd{RES\_INSECURE2} & Blocca i controlli di sicurezza di tipo 2.\\
358 \constd{RES\_NOALIASES} & Blocca l'uso della variabile di ambiente
359 \envvar{HOSTALIASES}.\\
360 \constd{RES\_USE\_INET6} & Restituisce indirizzi IPv6 con
361 \func{gethostbyname}. \\
362 \constd{RES\_ROTATE} & Ruota la lista dei server DNS dopo ogni
364 \constd{RES\_NOCHECKNAME}& Non controlla i nomi per verificarne la
365 correttezza sintattica. \\
366 \constd{RES\_KEEPTSIG} & Non elimina i record di tipo \texttt{TSIG}.\\
367 \constd{RES\_BLAST} & Effettua un ``\textit{blast}'' inviando
368 simultaneamente le richieste a tutti i server;
369 non ancora implementata. \\
370 \constd{RES\_DEFAULT} & Combinazione di \const{RES\_RECURSE},
371 \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}.\\
374 \caption{Costanti utilizzabili come valori per \var{\_res.options}.}
375 \label{tab:resolver_option}
378 Per utilizzare questa funzionalità per modificare le impostazioni direttamente
379 da programma occorrerà impostare un opportuno valore per questo campo ed
380 invocare esplicitamente \func{res\_init} o \func{res\_ninit}, dopo di che le
381 altre funzioni prenderanno le nuove impostazioni. Le costanti che definiscono
382 i vari bit di questo campo, ed il relativo significato sono illustrate in
383 tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
384 deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
385 esempio il valore di default delle opzioni, espresso dalla costante
386 \const{RES\_DEFAULT}, è definito come:
387 \includecodesnip{listati/resolv_option_def.c}
389 Non tratteremo il significato degli altri campi non essendovi necessità di
390 modificarli direttamente; gran parte di essi sono infatti impostati dal
391 contenuto dei file di configurazione, mentre le funzionalità controllate da
392 alcuni di esse possono essere modificate con l'uso delle opportune variabili
393 di ambiente come abbiamo visto per \envvar{LOCALDOMAIN}. In particolare con
394 \envvar{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
395 controlla quante volte viene ripetuto il tentativo di connettersi ad un server
396 DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
397 significa bloccare l'uso del DNS. Infine con \envvar{RES\_TIMEOUT} si
398 soprassiede il valore del campo \var{retrans} (preimpostato al valore della
399 omonima costante \const{RES\_TIMEOUT} di \headfile{resolv.h}) che è il valore
400 preso come base (in numero di secondi) per definire la scadenza di una
401 richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
402 il tempo di scadenza per il numero massimo di volte stabilito da
405 La funzione di interrogazione principale è \funcd{res\_query}
406 (\funcd{res\_nquery} per la nuova interfaccia), che serve ad eseguire una
407 richiesta ad un server DNS per un nome a dominio \textsl{completamente
408 specificato} (quello che si chiama
409 \itindex{Fully~Qualified~Domain~Name~(FQDN)} FQDN, \textit{Fully Qualified
410 Domain Name}); il loro prototipo è:
414 \fhead{arpa/nameser.h}
416 \fdecl{int res\_query(const char *dname, int class, int type,
417 unsigned char *answer, int anslen)}
418 \fdecl{int res\_nquery(res\_state statep, const char *dname, int class, int
420 \phantom{int res\_nquery(}unsigned char *answer, int anslen)}
421 \fdesc{Esegue una interrogazione al DNS.}
423 {Le funzioni ritornano un valore positivo pari alla lunghezza dei dati scritti
424 nel buffer \param{answer} in caso di successo e $-1$ per un errore.
428 Le funzioni eseguono una interrogazione ad un server DNS relativa al nome da
429 risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve
430 essere specificata la classe di indirizzi in cui eseguire la ricerca con
431 \param{class}, ed il tipo di \textit{resource record} che si vuole ottenere
432 con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
433 lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
434 allocato in precedenza.
436 Una seconda funzione di ricerca analoga a \func{res\_query}, che prende gli
437 stessi argomenti ma che esegue l'interrogazione con le funzionalità
438 addizionali previste dalle due opzioni \const{RES\_DEFNAMES} e
439 \const{RES\_DNSRCH}, è \funcd{res\_search} (\funcd{res\_nsearch} per la nuova
440 interfaccia), il cui prototipo è:
444 \fhead{arpa/nameser.h}
446 \fdecl{int res\_search(const char *dname, int class, int type,
447 unsigned char *answer, \\
448 \phantom{int res\_search}int anslen)}
449 \fdecl{int res\_nsearch(res\_state statep, const char *dname, int class,
451 \phantom{int res\_nsearch(}unsigned char *answer, int anslen)}
452 \fdesc{Esegue una interrogazione al DNS.}
454 {Le funzioni ritornano un valore positivo pari alla lunghezza dei dati scritti
455 nel buffer \param{answer} in caso di successo e $-1$ per un errore.
459 In sostanza la funzione ripete una serie di chiamate a \func{res\_query}
460 (\func{res\_nquery}) aggiungendo al nome contenuto nella stringa \param{dname}
461 il dominio di default da cercare, fermandosi non appena trova un risultato.
462 Il risultato di entrambe le funzioni viene scritto nel formato opportuno (che
463 sarà diverso a seconda del tipo di record richiesto) nel buffer di ritorno;
464 sarà compito del programma (o di altre funzioni) estrarre i relativi dati,
465 esistono una serie di funzioni interne usate per la scansione di questi dati,
466 per chi fosse interessato una trattazione dettagliata è riportata nel
467 quattordicesimo capitolo di \cite{DNSbind}.
469 Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in
470 pratica oggi viene utilizzata soltanto quella degli indirizzi internet; le
471 costanti che identificano dette classi, da usare come valore per l'argomento
472 \param{class} delle precedenti funzioni, sono riportate in
473 tab.~\ref{tab:DNS_address_class} (esisteva in realtà anche una classe
474 \constd{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta).
479 \begin{tabular}[c]{|l|p{8cm}|}
481 \textbf{Costante} & \textbf{Significato} \\
484 \constd{C\_IN} & Indirizzi internet, in pratica i soli utilizzati oggi.\\
485 \constd{C\_HS} & Indirizzi \textit{Hesiod}, utilizzati solo al MIT, oggi
486 completamente estinti. \\
487 \constd{C\_CHAOS}& Indirizzi per la rete \textit{Chaosnet}, un'altra rete
488 sperimentale nata al MIT. \\
489 \constd{C\_ANY} & Indica un indirizzo di classe qualunque.\\
492 \caption{Costanti identificative delle classi di indirizzi per l'argomento
493 \param{class} di \func{res\_query}.}
494 \label{tab:DNS_address_class}
497 Come accennato le tipologie di dati che sono mantenibili su un server DNS sono
498 diverse, ed a ciascuna di essa corrisponde un diverso tipo di \textit{resource
499 record}. L'elenco delle costanti, ripreso dai file di dichiarazione
500 \headfiled{arpa/nameser.h} e \headfiled{arpa/nameser\_compat.h}, che
501 definiscono i valori che si possono usare per l'argomento \param{type} per
502 specificare il tipo di \textit{resource record} da richiedere è riportato in
503 tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
504 hanno gli stessi nomi usati per identificare i record nei file di zona di
505 BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
506 implementazione di un server DNS, ed, essendo utilizzata nella stragrande
507 maggioranza dei casi, fa da riferimento; i dati relativi ad un certo dominio
508 (cioè i suoi \textit{resource record} vengono mantenuti in quelli che sono
509 usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo di dominio
510 è identificato da un nome che è appunto identico a quello delle costanti di
511 tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.} e che
512 normalmente sono anche usati come nomi per indicare i record.
517 \begin{tabular}[c]{|l|l|}
519 \textbf{Costante} & \textbf{Significato} \\
522 \constd{T\_A} & Indirizzo di una stazione.\\
523 \constd{T\_NS} & Server DNS autoritativo per il dominio richiesto.\\
524 \constd{T\_MD} & Destinazione per la posta elettronica.\\
525 \constd{T\_MF} & Redistributore per la posta elettronica.\\
526 \constd{T\_CNAME} & Nome canonico.\\
527 \constd{T\_SOA} & Inizio di una zona di autorità.\\
528 \constd{T\_MB} & Nome a dominio di una casella di posta.\\
529 \constd{T\_MG} & Nome di un membro di un gruppo di posta.\\
530 \constd{T\_MR} & Nome di un cambiamento di nome per la posta.\\
531 \constd{T\_NULL} & Record nullo.\\
532 \constd{T\_WKS} & Servizio noto.\\
533 \constd{T\_PTR} & Risoluzione inversa di un indirizzo numerico.\\
534 \constd{T\_HINFO} & Informazione sulla stazione.\\
535 \constd{T\_MINFO} & Informazione sulla casella di posta.\\
536 \constd{T\_MX} & Server cui instradare la posta per il dominio.\\
537 \constd{T\_TXT} & Stringhe di testo (libere).\\
538 \constd{T\_RP} & Nome di un responsabile (\textit{responsible person}).\\
539 \constd{T\_AFSDB} & Database per una cella AFS.\\
540 \constd{T\_X25} & Indirizzo di chiamata per X.25.\\
541 \constd{T\_ISDN} & Indirizzo di chiamata per ISDN.\\
542 \constd{T\_RT} & Router.\\
543 \constd{T\_NSAP} & Indirizzo NSAP.\\
544 \constd{T\_NSAP\_PTR}& Risoluzione inversa per NSAP (deprecato).\\
545 \constd{T\_SIG} & Firma digitale di sicurezza.\\
546 \constd{T\_KEY} & Chiave per firma.\\
547 \constd{T\_PX} & Corrispondenza per la posta X.400.\\
548 \constd{T\_GPOS} & Posizione geografica.\\
549 \constd{T\_AAAA} & Indirizzo IPv6.\\
550 \constd{T\_LOC} & Informazione di collocazione.\\
551 \constd{T\_NXT} & Dominio successivo.\\
552 \constd{T\_EID} & Identificatore di punto conclusivo.\\
553 \constd{T\_NIMLOC}& Posizionatore \textit{nimrod}.\\
554 \constd{T\_SRV} & Servizio.\\
555 \constd{T\_ATMA} & Indirizzo ATM.\\
556 \constd{T\_NAPTR} & Puntatore ad una \textit{naming authority}.\\
557 \constd{T\_TSIG} & Firma di transazione.\\
558 \constd{T\_IXFR} & Trasferimento di zona incrementale.\\
559 \constd{T\_AXFR} & Trasferimento di zona di autorità.\\
560 \constd{T\_MAILB} & Trasferimento di record di caselle di posta.\\
561 \constd{T\_MAILA} & Trasferimento di record di server di posta.\\
562 \constd{T\_ANY} & Valore generico.\\
565 \caption{Costanti identificative del tipo di record per l'argomento
566 \param{type} di \func{res\_query}.}
567 \label{tab:DNS_record_type}
571 L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
572 \textit{resource record} definiti, con una breve descrizione del relativo
573 significato. Di tutti questi però viene impiegato correntemente solo un
574 piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati
575 applicativi che non ci interessano non avendo nulla a che fare con la
576 risoluzione degli indirizzi IP, pertanto non entreremo nei dettagli del
577 significato di tutti i \textit{resource record}, ma solo di quelli usati dalle
578 funzioni del \textit{resolver}. Questi sono sostanzialmente i seguenti (per
579 indicarli si è usata la notazione dei file di zona di BIND):
580 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
581 \item[\texttt{A}] viene usato per indicare la corrispondenza fra un nome a
582 dominio ed un indirizzo IPv4; ad esempio la corrispondenza fra
583 \texttt{jojo.truelite.it} e l'indirizzo IP \texttt{62.48.34.25}.
584 \item[\texttt{AAAA}] viene usato per indicare la corrispondenza fra un nome a
585 dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
586 dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
587 \item[\texttt{PTR}] per fornire la corrispondenza inversa fra un indirizzo IP
588 ed un nome a dominio ad esso associato si utilizza questo tipo di record (il
589 cui nome sta per \textit{pointer}).
590 \item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
591 stesso indirizzo (come ad esempio \texttt{www.truelite.it} e
592 \texttt{sources.truelite.it}, che fanno entrambi riferimento alla stessa
593 macchina (nel caso \texttt{dodds.truelite.it}) si può usare questo tipo di
594 record per creare degli \textit{alias} in modo da associare un qualunque
595 altro nome al \textsl{nome canonico} della macchina (si chiama così quello
596 associato al record \texttt{A}).
599 Come accennato in caso di successo le due funzioni di richiesta restituiscono
600 il risultato della interrogazione al server, in caso di insuccesso l'errore
601 invece viene segnalato da un valore di ritorno pari a $-1$, ma in questo caso,
602 non può essere utilizzata la variabile \var{errno} per riportare un codice di
603 errore, in quanto questo viene impostato per ciascuna delle chiamate al
604 sistema utilizzate dalle funzioni del \textit{resolver}, non avrà alcun
605 significato nell'indicare quale parte del procedimento di risoluzione è
608 Per questo motivo è stata definita una variabile di errore separata,
609 \var{h\_errno}, che viene utilizzata dalle funzioni del \textit{resolver} per
610 indicare quale problema ha causato il fallimento della risoluzione del nome.
611 Ad essa si può accedere una volta che la si dichiara con:
612 \includecodesnip{listati/herrno.c}
613 ed i valori che può assumere, con il relativo significato, sono riportati in
614 tab.~\ref{tab:h_errno_values}.
619 \begin{tabular}[c]{|l|p{9cm}|}
621 \textbf{Costante} & \textbf{Significato} \\
624 \constd{HOST\_NOT\_FOUND}& L'indirizzo richiesto non è valido e la
625 macchina indicata è sconosciuta.\\
626 \constd{NO\_ADDRESS} & Il nome a dominio richiesto è valido, ma non ha
627 un indirizzo associato ad esso
628 (alternativamente può essere indicato come
629 \constd{NO\_DATA}).\\
630 \constd{NO\_RECOVERY} & Si è avuto un errore non recuperabile
631 nell'interrogazione di un server DNS.\\
632 \constd{TRY\_AGAIN} & Si è avuto un errore temporaneo
633 nell'interrogazione di un server DNS, si può
634 ritentare l'interrogazione in un secondo
638 \caption{Valori possibili della variabile \var{h\_errno}.}
639 \label{tab:h_errno_values}
642 Insieme alla nuova variabile vengono definite anche delle nuove funzioni per
643 stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror}
644 per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima è
645 \funcd{herror} ed il suo prototipo è:
651 \fdecl{void herror(const char *string)}
652 \fdesc{Stampa un errore di risoluzione.}
656 La funzione è l'analoga di \func{perror} e stampa sullo standard error un
657 messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui
658 viene anteposta la stringa \param{string} passata come argomento. La seconda
659 funzione è \funcd{hstrerror} ed il suo prototipo è:
665 \fdecl{const char *hstrerror(int err)}
666 \fdesc{Restituisce una stringa corrispondente ad un errore di risoluzione.}
670 \noindent che, come l'analoga \func{strerror}, restituisce una stringa con un
671 messaggio di errore già formattato, corrispondente al codice passato come
672 argomento (che si presume sia dato da \var{h\_errno}).
677 \subsection{La vecchia interfaccia per la risoluzione dei nomi a dominio}
678 \label{sec:sock_name_services}
680 La principale funzionalità del \textit{resolver} resta quella di risolvere i
681 nomi a dominio in indirizzi IP, per cui non ci dedicheremo oltre alle funzioni
682 per effetture delle richieste generiche al DNS ed esamineremo invece le
683 funzioni del \textit{resolver} dedicate specificamente a questo. Tratteremo in
684 questa sezione l'interfaccia tradizionale, che ormai è deprecata, mentre
685 vedremo nella sezione seguente la nuova interfaccia.
687 La prima funzione dell'interfaccia tradizionale è \funcd{gethostbyname} il cui
688 scopo è ottenere l'indirizzo di una stazione noto il suo nome a dominio, il
693 \fdecl{struct hostent *gethostbyname(const char *name)}
694 \fdesc{Determina l'indirizzo associato ad un nome a dominio.}
697 {La funzione ritorna il puntatore ad una
698 struttura di tipo \struct{hostent} contenente i dati associati al nome a
699 dominio in caso di successo o un puntatore nullo per un errore.}
702 La funzione prende come argomento una stringa \param{name} contenente il nome
703 a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
704 vengono memorizzati in una opportuna struttura \struct{hostent} la cui
705 definizione è riportata in fig.~\ref{fig:sock_hostent_struct}.
708 \footnotesize \centering
709 \begin{minipage}[c]{0.80\textwidth}
710 \includestruct{listati/hostent.h}
712 \caption{La struttura \structd{hostent} per la risoluzione dei nomi a
713 dominio e degli indirizzi IP.}
714 \label{fig:sock_hostent_struct}
717 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
718 effettuare la risoluzione del nome, è con i valori contenuti nei relativi
719 record che vengono riempite le varie parti della struttura \struct{hostent}.
720 Il primo campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
721 canonico}, che nel caso del DNS è appunto il nome associato ad un record
722 \texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
723 puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
724 puntatore del vettore punta ad una stringa contenente uno degli altri
725 possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel
726 DNS vengono inseriti come record di tipo \texttt{CNAME}).
728 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
729 che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
730 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
731 lunghezza dell'indirizzo stesso in byte.
733 Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
734 ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre,
735 come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
736 \var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
737 diretto al primo indirizzo della lista.
739 Oltre ai normali nomi a dominio la funzione accetta come argomento
740 \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
741 con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation} per IPv6. In
742 tal caso \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma
743 si limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
744 corrispondente struttura \var{in\_addr} da indirizzare con
745 \code{h\_addr\_list[0]}.
747 Con l'uso di \func{gethostbyname} si ottengono solo gli indirizzi IPv4, se si
748 vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare l'opzione
749 \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e poi chiamare
750 \func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per modificare
751 le opzioni del \textit{resolver}; dato che questo non è molto comodo è stata
752 definita (è una estensione fornita dalle \acr{glibc}, disponibile anche in
753 altri sistemi unix-like) un'altra funzione, \funcd{gethostbyname2}, il cui
759 \fdecl{struct hostent *gethostbyname2(const char *name, int af)}
760 \fdesc{Determina l'indirizzo del tipo scelto associato ad un nome a dominio.}
763 {La funzione ritorna il puntatore ad una
764 struttura di tipo \struct{hostent} contenente i dati associati al nome a
765 dominio in caso di successo e un puntatore nullo per un errore.}
768 In questo caso la funzione prende un secondo argomento \param{af} che indica
769 quale famiglia di indirizzi è quella che dovrà essere utilizzata per
770 selezionare i risultati restituiti dalla funzione; i soli valori consentiti
771 sono \const{AF\_INET} o \const{AF\_INET6} per indicare rispettivamente IPv4 e
772 IPv6 (per questo è necessario l'uso di \headfile{sys/socket.h}). Per tutto il
773 resto la funzione è identica a \func{gethostbyname}, ed identici sono i suoi
777 \footnotesize \centering
778 \begin{minipage}[c]{\codesamplewidth}
779 \includecodesample{listati/mygethost.c}
782 \caption{Esempio di codice per la risoluzione di un indirizzo.}
783 \label{fig:mygethost_example}
786 Vediamo allora un primo esempio dell'uso delle funzioni di risoluzione, in
787 fig.~\ref{fig:mygethost_example} è riportato un estratto del codice di un
788 programma che esegue una semplice interrogazione al \textit{resolver} usando
789 \func{gethostbyname} e poi ne stampa a video i risultati. Al solito il
790 sorgente completo, che comprende il trattamento delle opzioni ed una funzione
791 per stampare un messaggio di aiuto, è nel file \texttt{mygethost.c} dei
792 sorgenti allegati alla guida.
794 Il programma richiede un solo argomento che specifichi il nome da cercare,
795 senza il quale (\texttt{\small 15--18}) esce con un errore. Dopo di che
796 (\texttt{\small 20}) si limita a chiamare \func{gethostbyname}, ricevendo il
797 risultato nel puntatore \var{data}. Questo (\texttt{\small 21--24}) viene
798 controllato per rilevare eventuali errori, nel qual caso il programma esce
799 dopo aver stampato un messaggio con \func{herror}.
801 Se invece la risoluzione è andata a buon fine si inizia (\texttt{\small 25})
802 con lo stampare il nome canonico, dopo di che (\texttt{\small 26--30}) si
803 stampano eventuali altri nomi. Per questo prima (\texttt{\small 26}) si prende
804 il puntatore alla cima della lista che contiene i nomi e poi (\texttt{\small
805 27--30}) si esegue un ciclo che sarà ripetuto fin tanto che nella lista si
806 troveranno dei puntatori validi per le stringhe dei nomi (si ricordi che la
807 lista viene terminata da un puntatore nullo); prima (\texttt{\small 28}) si
808 stamperà la stringa e poi (\texttt{\small 29}) si provvederà ad incrementare
809 il puntatore per passare al successivo elemento della lista.
811 Una volta stampati i nomi si passerà a stampare gli indirizzi, il primo passo
812 (\texttt{\small 31--38}) è allora quello di riconoscere il tipo di indirizzo
813 sulla base del valore del campo \var{h\_addrtype}, stampandolo a video. Si è
814 anche previsto di stampare un errore nel caso (che non dovrebbe mai accadere)
815 di un indirizzo non valido.
817 Infine (\texttt{\small 39--44}) si stamperanno i valori degli indirizzi, di
818 nuovo (\texttt{\small 39}) si inizializzerà un puntatore alla cima della lista
819 e si eseguirà un ciclo fintanto che questo punterà ad indirizzi validi in
820 maniera analoga a quanto fatto in precedenza per i nomi a dominio. Si noti
821 come, essendo il campo \var{h\_addr\_list} un puntatore ad strutture di
822 indirizzi generiche, questo sia ancora di tipo \texttt{char **} e si possa
823 riutilizzare lo stesso puntatore usato per i nomi.
825 Per ciascun indirizzo valido si provvederà (\texttt{\small 41}) ad una
826 conversione con la funzione \func{inet\_ntop} (vedi
827 sez.~\ref{sec:sock_addr_func}) passandole gli opportuni argomenti, questa
828 restituirà la stringa da stampare (\texttt{\small 42}) con il valore
829 dell'indirizzo in \var{buffer}, che si è avuto la cura di dichiarare
830 inizialmente (\texttt{\small 10}) con dimensioni adeguate; dato che la
831 funzione è in grado di tenere conto automaticamente del tipo di indirizzo non
832 ci sono precauzioni particolari da prendere.\footnote{volendo essere pignoli
833 si dovrebbe controllarne lo stato di uscita, lo si è tralasciato per non
834 appesantire il codice, dato che in caso di indirizzi non validi si sarebbe
835 avuto un errore con \func{gethostbyname}, ma si ricordi che la sicurezza non
838 Le funzioni illustrate finora hanno un difetto: utilizzano tutte una area di
839 memoria interna per allocare i contenuti della struttura \struct{hostent} e
840 per questo non possono essere rientranti. L'uso della memoria interna inoltre
841 comporta anche che in due successive chiamate i dati potranno essere
844 Si tenga presente poi che copiare il contenuto della sola struttura non è
845 sufficiente per salvare tutti i dati, in quanto questa contiene puntatori ad
846 altri dati, che pure possono essere sovrascritti; per questo motivo, se si
847 vuole salvare il risultato di una chiamata, occorrerà eseguire quella che si
848 chiama una \itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così
849 quella tecnica per cui, quando si deve copiare il contenuto di una struttura
850 complessa (con puntatori che puntano ad altri dati, che a loro volta possono
851 essere puntatori ad altri dati) si deve copiare non solo il contenuto della
852 struttura, ma eseguire una scansione per risolvere anche tutti i puntatori
853 contenuti in essa (e così via se vi sono altre sotto-strutture con altri
854 puntatori) e copiare anche i dati da questi referenziati.}
856 Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
857 versioni rientranti delle precedenti funzioni, al solito queste sono
858 caratterizzate dall'avere un suffisso \texttt{\_r}, pertanto avremo le due
859 funzioni \funcd{gethostbyname\_r} e \funcd{gethostbyname2\_r} i cui prototipi
865 \fdecl{int gethostbyname\_r(const char *name, struct hostent *ret,
866 char *buf, size\_t buflen,\\
867 \phantom{int gethostbyname\_r(}struct hostent **result, int *h\_errnop)}
868 \fdecl{int gethostbyname2\_r(const char *name, int af,
869 struct hostent *ret, char *buf,\\
870 \phantom{int gethostbyname2\_r(}size\_t buflen, struct hostent **result, int *h\_errnop)}
872 \fdesc{Versioni rientranti delle funzioni \func{gethostbyname} e
873 \func{gethostbyname2}.}
876 {Le funzioni ritornano $0$ in caso di successo ed un valore diverso da zero per
880 Gli argomenti \param{name} (e \param{af} per \func{gethostbyname2\_r}) hanno
881 lo stesso significato visto in precedenza. Tutti gli altri argomenti hanno lo
882 stesso significato per entrambe le funzioni. Per evitare l'uso di variabili
883 globali si dovrà allocare preventivamente una struttura \struct{hostent} in
884 cui ricevere il risultato, passandone l'indirizzo alla funzione nell'argomento
885 \param{ret}. Inoltre, dato che \struct{hostent} contiene dei puntatori, dovrà
886 essere allocato anche un buffer in cui le funzioni possano scrivere tutti i
887 dati del risultato dell'interrogazione da questi puntati; l'indirizzo e la
888 lunghezza di questo buffer devono essere indicati con gli argomenti
889 \param{buf} e \param{buflen}.
891 Gli ultimi due argomenti vengono utilizzati per avere indietro i risultati
892 come \textit{value result argument}, si deve specificare l'indirizzo della
893 variabile su cui la funzione dovrà salvare il codice di errore
894 con \param{h\_errnop} e quello su cui dovrà salvare il puntatore che si userà
895 per accedere i dati con \param{result}.
897 In caso di successo entrambe le funzioni restituiscono un valore nullo,
898 altrimenti restituiscono un valore non nulla e all'indirizzo puntato
899 da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
900 \param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
901 essere rientrante la funzione non può la variabile globale \var{h\_errno}. In
902 questo caso il codice di errore, oltre ai valori di
903 tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
904 qualora il buffer allocato su \param{buf} non sia sufficiente a contenere i
905 dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
906 con un buffer di dimensione maggiore.
908 Una delle caratteristiche delle interrogazioni al servizio DNS è che queste
909 sono normalmente eseguite con il protocollo UDP, ci sono casi in cui si
910 preferisce che vengano usate connessioni permanenti con il protocollo TCP. Per
911 ottenere questo sono previste delle funzioni apposite (si potrebbero impostare
912 direttamente le opzioni di \var{\_\_res.options}, ma queste funzioni
913 permettono di semplificare la procedura); la prime sono \funcd{sethostent} e
914 \func{endhostent}, il cui prototipo è:
918 \fdecl{void sethostent(int stayopen)}
919 \fdesc{Richiede l'uso di connessioni TCP per le interrogazioni ad un server DNS.}
920 \fdecl{void endhostent(void)}
921 \fdesc{Disattiva l'uso di connessioni TCP per le interrogazioni ad un server DNS.}
924 {Le funzioni non restituiscono nulla, e non danno errori.}
927 La funzione \func{sethostent} permette di richiedere l'uso di connessioni TCP
928 per la richiesta dei dati, e che queste restino aperte per successive
929 richieste; il valore dell'argomento \param{stayopen} indica se attivare questa
930 funzionalità, un valore diverso da zero, che indica una condizione vera in C,
931 attiva la funzionalità. Per disattivare l'uso delle connessioni TCP si può
932 invece usare \func{endhostent}, e come si vede la funzione è estremamente
933 semplice, non richiedendo nessun argomento.
935 Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
936 per ottenerne il nome a dominio ad esso associato, per fare questo si può
937 usare la funzione \funcd{gethostbyaddr}, il cui prototipo è:
942 \fdecl{struct hostent *gethostbyaddr(const char *addr, int len, int type)}
943 \fdesc{Richiede la risoluzione inversa di un indirizzo IP.}
946 {La funzione ritorna l'indirizzo ad una struttura \struct{hostent} in caso di
947 successo e \val{NULL} per un errore.}
950 In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
951 appropriata struttura contenente il valore dell'indirizzo IP (o IPv6) che si
952 vuole risolvere. L'uso del tipo \texttt{char *} per questo argomento è
953 storico, il dato dovrà essere fornito in una struttura \struct{in\_addr} per
954 un indirizzo IPv4 ed una struttura \struct{in6\_addr} per un indirizzo IPv6;
955 si ricordi che, come illustrato in fig.~\ref{fig:sock_sa_ipv4_struct}, che
956 mentre \struct{in\_addr} in realtà corrisponde ad un numero intero, da
957 esprimere comunque in \textit{network order}, non altrettanto avviene per
958 \struct{in6\_addr}, pertanto è sempre opportuno inizializzare questi indirizzi
959 con \func{inet\_pton} (vedi
960 sez.~\ref{sec:sock_conv_func_gen}). Nell'argomento \param{len} se ne dovrà poi
961 specificare la dimensione (rispettivamente 4 o 16), infine l'argomento
962 \param{type} deve indicare il tipo di indirizzo, e dovrà essere o
963 \const{AF\_INET} o \const{AF\_INET6}.
965 La funzione restituisce, in caso di successo, un puntatore ad una struttura
966 \struct{hostent}, solo che in questo caso la ricerca viene eseguita
967 richiedendo al DNS un record di tipo \texttt{PTR} corrispondente all'indirizzo
968 specificato. In caso di errore al solito viene usata la variabile
969 \var{h\_errno} per restituire un opportuno codice. In questo caso l'unico
970 campo del risultato che interessa è \var{h\_name} che conterrà il nome a
971 dominio, la funzione comunque inizializza anche il primo campo della lista
972 \var{h\_addr\_list} col valore dell'indirizzo passato come argomento.
974 Dato che \func{gethostbyaddr} usa un buffer statico, anche di questa funzione
975 esiste una versione rientrante \funcd{gethostbyaddr\_r} fornita come
976 estensione dalle \acr{glibc}, il cui prototipo è:
981 \fdecl{struct hostent *gethostbyaddr\_r(const void *addr, socklen\_t len, int type,\\
982 \phantom{struct hostent *gethostbyaddr\_r(}struct hostent *ret, char *buf, size\_t buflen,\\
983 \phantom{struct hostent *gethostbyaddr\_r(}struct hostent **result, int *h\_errnop);}
984 \fdesc{Richiede la risoluzione inversa di un indirizzo IP.}
987 {La funzione ritorna $0$ in caso di successo e un valore non nullo per un errore.}
990 La funzione prende per gli argomenti \param{addr}, \param{len} e \param{type}
991 gli stessi valori di \func{gethostbyaddr} con lo stesso significato, gli
992 argomenti successivi vengono utilizzati per restituire i dati, sono identici a
993 quelli già illustrati in per \func{gethostbyname\_r} e
994 \func{gethostbyname2\_r} e devono essere usati allo stesso modo.
996 Infine lo standard POSIX prevede la presenza della funzione
997 \funcm{gethostent}, che dovrebbe ritornare la voce successiva nel database dei
998 nomi a dominio, ma questo ha senso solo per la lettura dei dati da un file
999 come \conffile{/etc/hosts} e non per i risultati del DNS. Nel caso della
1000 \acr{glibc} questa viene usata allora solo per la lettura di quest'ultimo,
1001 come avviene in altri sistemi, ed ignora le voci relative ad indirizzi
1002 IPv6. Dato che i risultati si possono ottenere in modo generico con le
1003 funzioni già illustrate, non la tratteremo esplicitamente, come non tratteremo
1004 la sua variante rientrante \funcm{gethostent\_r}.
1006 Per risolvere il problema dell'uso da parte delle due funzioni
1007 \func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
1008 sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
1009 indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
1010 con \func{gethostbyname}), seguendo
1011 l'\href{http://www.ietf.org/rfc/rfc2553.txt}{RFC~2553} vennero introdotte due
1012 nuove funzioni di risoluzione,\footnote{le funzioni sono presenti nelle
1013 \acr{glibc} versione 2.1.96, ma essendo considerate deprecate (vedi
1014 sez.~\ref{sec:sock_advanced_name_services}) sono state rimosse nelle
1015 versioni successive.} \funcd{getipnodebyname} e \funcd{getipnodebyaddr}, i
1021 \fhead{sys/socket.h}
1022 \fdecl{struct hostent *getipnodebyname(const char *name, int af, int
1023 flags, int *error\_num)}
1024 \fdesc{Richiede la risoluzione di un nome a dominio.}
1025 \fdecl{struct hostent *getipnodebyaddr(const void *addr, size\_t len,
1026 int af, int *error\_num)}
1027 \fdesc{Richiede la risoluzione inversa di un indirizzo IP.}
1030 {Le funzioni ritornano l'indirizzo ad una struttura \struct{hostent} in caso
1031 di successo e \val{NULL} per un errore.}
1034 Entrambe le funzioni supportano esplicitamente la scelta di una famiglia di
1035 indirizzi con l'argomento \param{af} (che può assumere i valori
1036 \const{AF\_INET} o \const{AF\_INET6}), e restituiscono un codice di errore
1037 (con valori identici a quelli precedentemente illustrati in
1038 tab.~\ref{tab:h_errno_values}) nella variabile puntata da \param{error\_num}.
1039 La funzione \func{getipnodebyaddr} richiede poi che si specifichi l'indirizzo
1040 come per \func{gethostbyaddr} passando anche la lunghezza dello stesso
1041 nell'argomento \param{len}.
1043 La funzione \func{getipnodebyname} prende come primo argomento il nome da
1044 risolvere, inoltre prevede un apposito argomento \param{flags}, da usare come
1045 maschera binaria, che permette di specificarne il comportamento nella
1046 risoluzione dei diversi tipi di indirizzi (IPv4 e IPv6); ciascun bit
1047 dell'argomento esprime una diversa opzione, e queste possono essere specificate
1048 con un OR aritmetico delle costanti riportate in
1049 tab.~\ref{tab:sock_getipnodebyname_flags}.
1054 \begin{tabular}[c]{|l|p{8cm}|}
1056 \textbf{Costante} & \textbf{Significato} \\
1059 \constd{AI\_V4MAPPED} & Usato con \const{AF\_INET6} per richiedere una
1060 ricerca su un indirizzo IPv4 invece che IPv6; gli
1061 eventuali risultati saranno rimappati su indirizzi
1063 \constd{AI\_ALL} & Usato con \const{AI\_V4MAPPED}; richiede sia
1064 indirizzi IPv4 che IPv6, e gli indirizzi IPv4
1065 saranno rimappati in IPv6.\\
1066 \constd{AI\_ADDRCONFIG}& Richiede che una richiesta IPv4 o IPv6 venga
1067 eseguita solo se almeno una interfaccia del
1068 sistema è associata ad un indirizzo di tale tipo.\\
1069 \constd{AI\_DEFAULT} & Il valore di default, è equivalente alla
1070 combinazione di \const{AI\_ADDRCONFIG} e di
1071 \const{AI\_V4MAPPED}.\\
1074 \caption{Valori possibili per i bit dell'argomento \param{flags} della
1075 funzione \func{getipnodebyname}.}
1076 \label{tab:sock_getipnodebyname_flags}
1079 Entrambe le funzioni restituiscono un puntatore ad una struttura \var{hostent}
1080 che contiene i risultati della ricerca, che viene allocata dinamicamente
1081 insieme a tutto lo spazio necessario a contenere i dati in essa referenziati;
1082 per questo motivo queste funzioni non soffrono dei problemi dovuti all'uso di
1083 una sezione statica di memoria presenti con le precedenti \func{gethostbyname}
1084 e \func{gethostbyaddr}. L'uso di una allocazione dinamica però comporta anche
1085 la necessità di disallocare esplicitamente la memoria occupata dai risultati
1086 una volta che questi non siano più necessari; a tale scopo viene fornita la
1087 funzione \funcd{freehostent}, il cui prototipo è:
1093 \fhead{sys/socket.h}
1094 \fdecl{void freehostent(struct hostent *ip)}
1095 \fdesc{Disalloca una struttura \var{hostent}.}
1098 {La funzione non ritorna nulla, e non da errori.}
1101 La funzione permette di disallocare una struttura \var{hostent}
1102 precedentemente allocata in una chiamata di \func{getipnodebyname} o
1103 \func{getipnodebyaddr}, e prende come argomento l'indirizzo restituito da una
1106 Infine per concludere la nostra panoramica sulle funzioni di risoluzione dei
1107 nomi dobbiamo citare le funzioni che permettono di interrogare gli altri
1108 servizi di risoluzione dei nomi illustrati in sez.~\ref{sec:sock_resolver}; in
1109 generale infatti ci sono una serie di funzioni nella forma
1110 \texttt{getXXXbyname} e \texttt{getXXXbyaddr} (dove \texttt{XXX} indica il
1111 servizio) per ciascuna delle informazioni di rete mantenute dal \textit{Name
1112 Service Switch} che permettono rispettivamente di trovare una corrispondenza
1113 cercando per nome o per numero.
1115 L'elenco di queste funzioni è riportato nelle colonne finali di
1116 tab.~\ref{tab:name_resolution_functions}, dove le si sono suddivise rispetto
1117 al tipo di informazione che forniscono (riportato in prima colonna). Nella
1118 tabella si è anche riportato il file su cui vengono ordinariamente mantenute
1119 queste informazioni, che però può essere sostituito da un qualunque supporto
1120 interno al \textit{Name Service Switch} (anche se usualmente questo avviene
1121 solo per la risoluzione degli indirizzi). Ciascuna funzione fa riferimento ad
1122 una sua apposita struttura che contiene i relativi dati, riportata in terza
1128 \begin{tabular}[c]{|l|l|l|l|l|}
1130 \textbf{Informazione}&\textbf{File}&\textbf{Struttura}&
1131 \multicolumn{2}{|c|}{\textbf{Funzioni}}\\
1134 indirizzo &\conffile{/etc/hosts}&\struct{hostent}&\func{gethostbyname}&
1135 \func{gethostbyaddr}\\
1136 servizio &\conffile{/etc/services}&\struct{servent}&\func{getservbyname}&
1137 \func{getservbyport}\\
1138 rete &\conffile{/etc/networks}&\struct{netent}&\funcm{getnetbyname}&
1139 \funcm{getnetbyaddr}\\
1140 protocollo&\conffile{/etc/protocols}&\struct{protoent}&
1141 \funcm{getprotobyname}&\funcm{getprotobyaddr}\\
1144 \caption{Funzioni di risoluzione dei nomi per i vari servizi del
1145 \textit{Name Service Switch} riguardanti la rete.}
1146 \label{tab:name_resolution_functions}
1149 Delle funzioni di tab.~\ref{tab:name_resolution_functions} abbiamo trattato
1150 finora soltanto quelle relative alla risoluzione dei nomi, dato che sono le
1151 più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
1152 una entità esterna; per le altre invece, estensioni fornite dal \textit{Name
1153 Service Switch} a parte, si fa sempre riferimento ai dati mantenuti nei
1156 Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
1157 sui nomi dei servizi di rete più comuni (cioè \texttt{http}, \texttt{smtp},
1158 ecc.) da associare alle rispettive porte. Le due funzioni da utilizzare per
1159 questo sono \funcd{getservbyname} e \funcd{getservbyport}, che permettono
1160 rispettivamente di ottenere il numero di porta associato ad un servizio dato
1161 il nome e viceversa; i loro prototipi sono:
1164 \funcdecl{struct servent *getservbyname(const char *name, const char *proto)}
1165 \funcdecl{struct servent *getservbyport(int port, const char *proto)}
1167 Risolvono il nome di un servizio nel rispettivo numero di porta e viceversa.
1169 \bodydesc{Ritornano il puntatore ad una struttura \struct{servent} con i
1170 risultati in caso di successo, o \val{NULL} in caso di errore.}
1173 Entrambe le funzioni prendono come ultimo argomento una stringa \param{proto}
1174 che indica il protocollo per il quale si intende effettuare la
1175 ricerca,\footnote{le informazioni mantenute in \conffile{/etc/services}
1176 infatti sono relative sia alle porte usate su UDP che su TCP, occorre quindi
1177 specificare a quale dei due protocolli si fa riferimento.} che nel caso si
1178 IP può avere come valori possibili solo \texttt{udp} o
1179 \texttt{tcp};\footnote{in teoria si potrebbe avere un qualunque protocollo fra
1180 quelli citati in \conffile{/etc/protocols}, posto che lo stesso supporti il
1181 concetto di \textsl{porta}, in pratica questi due sono gli unici presenti.}
1182 se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
1185 Il primo argomento è il nome del servizio per \func{getservbyname},
1186 specificato tramite la stringa \param{name}, mentre \func{getservbyport}
1187 richiede il numero di porta in \param{port}. Entrambe le funzioni eseguono una
1188 ricerca sul file \conffile{/etc/services}\footnote{il \textit{Name Service
1189 Switch} astrae il concetto a qualunque supporto su cui si possano
1190 mantenere i suddetti dati.} ed estraggono i dati dalla prima riga che
1191 corrisponde agli argomenti specificati; se la risoluzione ha successo viene
1192 restituito un puntatore ad una apposita struttura \struct{servent} contenente
1193 tutti i risultati, altrimenti viene restituito un puntatore nullo. Si tenga
1194 presente che anche in questo caso i dati vengono mantenuti in una area di
1195 memoria statica e che quindi la funzione non è rientrante.
1197 \begin{figure}[!htb]
1198 \footnotesize \centering
1199 \begin{minipage}[c]{0.80\textwidth}
1200 \includestruct{listati/servent.h}
1202 \caption{La struttura \structd{servent} per la risoluzione dei nomi dei
1203 servizi e dei numeri di porta.}
1204 \label{fig:sock_servent_struct}
1207 La definizione della struttura \struct{servent} è riportata in
1208 fig.~\ref{fig:sock_servent_struct}, il primo campo, \var{s\_name} contiene
1209 sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
1210 ad un vettore di stringhe contenenti gli eventuali nomi alternativi
1211 utilizzabili per identificare lo stesso servizio. Infine \var{s\_port}
1212 contiene il numero di porta e \var{s\_proto} il nome del protocollo.
1214 Come riportato in tab.~\ref{tab:name_resolution_functions} ci sono analoghe
1215 funzioni per la risoluzione del nome dei protocolli e delle reti; non staremo
1216 a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
1217 comunque utilizzano una loro struttura dedicata del tutto analoga alle
1218 precedenti: tutti i dettagli relativi al loro funzionamento possono essere
1219 trovati nelle rispettive pagine di manuale.
1221 Oltre alle funzioni di ricerca esistono delle ulteriori funzioni che prevedono
1222 una lettura sequenziale delle informazioni mantenute nel \textit{Name Service
1223 Switch} (in sostanza permettono di leggere i file contenenti le informazioni
1224 riga per riga), che sono analoghe a quelle elencate in
1225 tab.~\ref{tab:sys_passwd_func} per le informazioni relative ai dati degli
1226 utenti e dei gruppi. Nel caso specifico dei servizi avremo allora le tre
1227 funzioni \funcd{setservent}, \funcd{getservent} e \funcd{endservent} i cui
1231 \funcdecl{void setservent(int stayopen)}
1232 Apre il file \conffile{/etc/services} e si posiziona al suo inizio.
1234 \funcdecl{struct servent *getservent(void)}
1235 Legge la voce successiva nel file \conffile{/etc/services}.
1237 \funcdecl{void endservent(void)}
1238 Chiude il file \conffile{/etc/services}.
1240 \bodydesc{Le due funzioni \func{setservent} e \func{endservent} non
1241 restituiscono nulla, \func{getservent} restituisce il puntatore ad una
1242 struttura \struct{servent} in caso di successo e \val{NULL} in caso di
1243 errore o fine del file.}
1246 La prima funzione, \func{getservent}, legge una singola voce a partire dalla
1247 posizione corrente in \conffile{/etc/services}, pertanto si può eseguire una
1248 lettura sequenziale dello stesso invocandola più volte. Se il file non è
1249 aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
1250 voce. La seconda funzione, \func{setservent}, permette di aprire il file
1251 \conffile{/etc/services} per una successiva lettura, ma se il file è già stato
1252 aperto riporta la posizione di lettura alla prima voce del file, in questo
1253 modo si può far ricominciare da capo una lettura sequenziale. L'argomento
1254 \param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
1255 diverse chiamate a \func{getservbyname} e \func{getservbyport}.\footnote{di
1256 default dopo una chiamata a queste funzioni il file viene chiuso, cosicché
1257 una successiva chiamata a \func{getservent} riparte dall'inizio.} La terza
1258 funzione, \func{endservent}, provvede semplicemente a chiudere il file.
1260 Queste tre funzioni per la lettura sequenziale di nuovo sono presenti per
1261 ciascuno dei vari tipi di informazione relative alle reti di
1262 tab.~\ref{tab:name_resolution_functions}; questo significa che esistono
1263 altrettante funzioni nella forma \texttt{setXXXent}, \texttt{getXXXent} e
1264 \texttt{endXXXent}, analoghe alle precedenti per la risoluzione dei servizi,
1265 che abbiamo riportato in tab.~\ref{tab:name_sequential_read}. Essendo, a
1266 parte il tipo di informazione che viene trattato, sostanzialmente identiche
1267 nel funzionamento e di scarso utilizzo, non staremo a trattarle una per una,
1268 rimandando alle rispettive pagine di manuale.
1273 \begin{tabular}[c]{|l|l|l|l|}
1275 \textbf{Informazione}&\multicolumn{3}{|c|}{\textbf{Funzioni}}\\
1278 indirizzo &\func{sethostent} &\func{gethostent} &\func{endhostent} \\
1279 servizio &\func{setservent} &\func{getservent} &\func{endservent}\\
1280 rete &\funcm{setnetent} &\funcm{getnetent} &\funcm{endnetent}\\
1281 protocollo&\funcm{setprotoent}&\funcm{getprotoent}&\funcm{endprotoent}\\
1284 \caption{Funzioni lettura sequenziale dei dati del
1285 \textit{Name Service Switch}.}
1286 \label{tab:name_sequential_read}
1290 \subsection{Le funzioni avanzate per la risoluzione dei nomi}
1291 \label{sec:sock_advanced_name_services}
1293 Quelle illustrate nella sezione precedente sono le funzioni classiche per la
1294 risoluzione di nomi ed indirizzi IP, ma abbiamo già visto come esse soffrano
1295 di vari inconvenienti come il fatto che usano informazioni statiche, e non
1296 prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
1297 state create delle estensioni o metodi diversi che permettono di risolvere
1298 alcuni di questi inconvenienti,\footnote{rimane ad esempio il problema
1299 generico che si deve sapere in anticipo quale tipo di indirizzi IP (IPv4 o
1300 IPv6) corrispondono ad un certo nome a dominio.} comunque esse non
1301 forniscono una interfaccia sufficientemente generica.
1303 Inoltre in genere quando si ha a che fare con i socket non esiste soltanto il
1304 problema della risoluzione del nome che identifica la macchina, ma anche
1305 quello del servizio a cui ci si vuole rivolgere. Per questo motivo con lo
1306 standard POSIX 1003.1-2001 sono state indicate come deprecate le varie
1307 funzioni \func{gethostbyaddr}, \func{gethostbyname}, \var{getipnodebyname} e
1308 \var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
1311 La prima funzione di questa interfaccia è \funcd{getaddrinfo},\footnote{la
1312 funzione è definita, insieme a \func{getnameinfo} che vedremo più avanti,
1313 nell'\href{http://www.ietf.org/rfc/rfc2553.txt}{RFC~2553}.} che combina le
1314 funzionalità delle precedenti \func{getipnodebyname}, \func{getipnodebyaddr},
1315 \func{getservbyname} e \func{getservbyport}, consentendo di ottenere
1316 contemporaneamente sia la risoluzione di un indirizzo simbolico che del nome
1317 di un servizio; il suo prototipo è:
1320 \headdecl{sys/socket.h}
1323 \funcdecl{int getaddrinfo(const char *node, const char *service, const
1324 struct addrinfo *hints, struct addrinfo **res)}
1326 Esegue una risoluzione di un nome a dominio e di un nome di servizio.
1328 \bodydesc{La funzione restituisce 0 in caso di successo o un codice di
1329 errore diverso da zero in caso di fallimento.}
1332 La funzione prende come primo argomento il nome della macchina che si vuole
1333 risolvere, specificato tramite la stringa \param{node}. Questo argomento,
1334 oltre ad un comune nome a dominio, può indicare anche un indirizzo numerico in
1335 forma \textit{dotted-decimal} per IPv4 o in formato esadecimale per IPv6. Si
1336 può anche specificare il nome di una rete invece che di una singola macchina.
1337 Il secondo argomento, \param{service}, specifica invece il nome del servizio
1338 che si intende risolvere. Per uno dei due argomenti si può anche usare il
1339 valore \val{NULL}, nel qual caso la risoluzione verrà effettuata soltanto
1340 sulla base del valore dell'altro.
1342 Il terzo argomento, \param{hints}, deve essere invece un puntatore ad una
1343 struttura \struct{addrinfo} usata per dare dei \textsl{suggerimenti} al
1344 procedimento di risoluzione riguardo al protocollo o del tipo di socket che si
1345 intenderà utilizzare; \func{getaddrinfo} infatti permette di effettuare
1346 ricerche generiche sugli indirizzi, usando sia IPv4 che IPv6, e richiedere
1347 risoluzioni sui nomi dei servizi indipendentemente dal protocollo (ad esempio
1348 TCP o UDP) che questi possono utilizzare.
1350 Come ultimo argomento in \param{res} deve essere passato un puntatore ad una
1351 variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
1352 utilizzata dalla funzione per riportare (come \textit{value result argument})
1353 i propri risultati. La funzione infatti è rientrante, ed alloca autonomamente
1354 tutta la memoria necessaria in cui verranno riportati i risultati della
1355 risoluzione. La funzione scriverà all'indirizzo puntato da \param{res} il
1356 puntatore iniziale ad una \textit{linked list} di strutture di tipo
1357 \struct{addrinfo} contenenti tutte le informazioni ottenute.
1359 \begin{figure}[!htb]
1360 \footnotesize \centering
1361 \begin{minipage}[c]{0.80\textwidth}
1362 \includestruct{listati/addrinfo.h}
1364 \caption{La struttura \structd{addrinfo} usata nella nuova interfaccia POSIX
1365 per la risoluzione di nomi a dominio e servizi.}
1366 \label{fig:sock_addrinfo_struct}
1369 Come illustrato la struttura \struct{addrinfo}, la cui definizione è riportata
1370 in fig.~\ref{fig:sock_addrinfo_struct}, viene usata sia in ingresso, per
1371 passare dei valori di controllo alla funzione, che in uscita, per ricevere i
1372 risultati. La definizione è ripresa direttamente dal file \headfiled{netdb.h}
1373 in questa struttura viene dichiarata, la pagina di manuale riporta
1374 \type{size\_t} come tipo di dato per il campo \var{ai\_addrlen}, qui viene
1375 usata quanto previsto dallo standard POSIX, in cui viene utilizzato
1376 \type{socklen\_t}; i due tipi di dati sono comunque equivalenti.
1378 Il primo campo, \var{ai\_flags}, è una maschera binaria di bit che
1379 permettono di controllare le varie modalità di risoluzione degli indirizzi,
1380 che viene usato soltanto in ingresso. I tre campi successivi \var{ai\_family},
1381 \var{ai\_socktype}, e \var{ai\_protocol} contengono rispettivamente la
1382 famiglia di indirizzi, il tipo di socket e il protocollo, in ingresso vengono
1383 usati per impostare una selezione (impostandone il valore nella struttura
1384 puntata da \param{hints}), mentre in uscita indicano il tipo di risultato
1385 contenuto nella struttura.
1387 Tutti i campi seguenti vengono usati soltanto in uscita; il campo
1388 \var{ai\_addrlen} indica la dimensione della struttura degli indirizzi
1389 ottenuta come risultato, il cui contenuto sarà memorizzato nella struttura
1390 \struct{sockaddr} posta all'indirizzo puntato dal campo \var{ai\_addr}. Il
1391 campo \var{ai\_canonname} è un puntatore alla stringa contenente il nome
1392 canonico della macchina, ed infine, quando la funzione restituisce più di un
1393 risultato, \var{ai\_next} è un puntatore alla successiva struttura
1394 \struct{addrinfo} della lista.
1396 Ovviamente non è necessario dare dei suggerimenti in ingresso, ed usando
1397 \val{NULL} come valore per l'argomento \param{hints} si possono compiere
1398 ricerche generiche. Se però si specifica un valore non nullo questo deve
1399 puntare ad una struttura \struct{addrinfo} precedentemente allocata nella
1400 quale siano stati opportunamente impostati i valori dei campi
1401 \var{ai\_family}, \var{ai\_socktype}, \var{ai\_protocol} ed \var{ai\_flags}.
1403 I due campi \var{ai\_family} e \var{ai\_socktype} prendono gli stessi valori
1404 degli analoghi argomenti della funzione \func{socket}; in particolare per
1405 \var{ai\_family} si possono usare i valori di tab.~\ref{tab:net_pf_names} ma
1406 sono presi in considerazione solo \const{PF\_INET} e \const{PF\_INET6}, mentre
1407 se non si vuole specificare nessuna famiglia di indirizzi si può usare il
1408 valore \const{PF\_UNSPEC}. Allo stesso modo per \var{ai\_socktype} si possono
1409 usare i valori illustrati in sez.~\ref{sec:sock_type} per indicare per quale
1410 tipo di socket si vuole risolvere il servizio indicato, anche se i soli
1411 significativi sono \const{SOCK\_STREAM} e \const{SOCK\_DGRAM}; in questo caso,
1412 se non si vuole effettuare nessuna risoluzione specifica, si potrà usare un
1415 Il campo \var{ai\_protocol} permette invece di effettuare la selezione dei
1416 risultati per il nome del servizio usando il numero identificativo del
1417 rispettivo protocollo di trasporto (i cui valori possibili sono riportati in
1418 \conffile{/etc/protocols}); di nuovo i due soli valori utilizzabili sono quelli
1419 relativi a UDP e TCP, o il valore nullo che indica di ignorare questo campo
1425 \begin{tabular}[c]{|l|p{10cm}|}
1427 \textbf{Costante} & \textbf{Significato} \\
1430 \constd{AI\_PASSIVE} & Viene utilizzato per ottenere un indirizzo in
1431 formato adatto per una successiva chiamata a
1432 \func{bind}. Se specificato quando si è usato
1433 \val{NULL} come valore per \param{node} gli
1434 indirizzi restituiti saranno inizializzati al
1435 valore generico (\const{INADDR\_ANY} per IPv4 e
1436 \const{IN6ADDR\_ANY\_INIT} per IPv6), altrimenti
1437 verrà usato l'indirizzo dell'interfaccia di
1438 \textit{loopback}. Se invece non è impostato gli
1439 indirizzi verranno restituiti in formato adatto ad
1440 una chiamata a \func{connect} o \func{sendto}.\\
1441 \constd{AI\_CANONNAME} & Richiede la restituzione del nome canonico della
1442 macchina, che verrà salvato in una stringa il cui
1443 indirizzo sarà restituito nel campo
1444 \var{ai\_canonname} della prima struttura
1445 \struct{addrinfo} dei risultati. Se il nome
1446 canonico non è disponibile al suo posto
1447 viene restituita una copia di \param{node}. \\
1448 \constd{AI\_NUMERICHOST}& Se impostato il nome della macchina specificato
1449 con \param{node} deve essere espresso in forma
1450 numerica, altrimenti sarà restituito un errore
1451 \const{EAI\_NONAME} (vedi
1452 tab.~\ref{tab:addrinfo_error_code}), in questo
1453 modo si evita ogni chiamata alle funzioni di
1455 \const{AI\_V4MAPPED} & Stesso significato dell'analoga di
1456 tab.~\ref{tab:sock_getipnodebyname_flags}.\\
1457 \const{AI\_ALL} & Stesso significato dell'analoga di
1458 tab.~\ref{tab:sock_getipnodebyname_flags}.\\
1459 \const{AI\_ADDRCONFIG} & Stesso significato dell'analoga di
1460 tab.~\ref{tab:sock_getipnodebyname_flags}.\\
1463 \caption{Costanti associate ai bit del campo \var{ai\_flags} della struttura
1465 \label{tab:ai_flags_values}
1469 Infine l'ultimo campo è \var{ai\_flags}; che deve essere impostato come una
1470 maschera binaria; i bit di questa variabile infatti vengono usati per dare
1471 delle indicazioni sul tipo di risoluzione voluta, ed hanno valori analoghi a
1472 quelli visti in sez.~\ref{sec:sock_name_services} per \func{getipnodebyname};
1473 il valore di \var{ai\_flags} può essere impostata con un OR aritmetico delle
1474 costanti di tab.~\ref{tab:ai_flags_values}, ciascuna delle quali identifica un
1477 La funzione restituisce un valore nullo in caso di successo, o un codice in
1478 caso di errore. I valori usati come codice di errore sono riportati in
1479 tab.~\ref{tab:addrinfo_error_code}; dato che la funzione utilizza altre
1480 funzioni e chiamate al sistema per ottenere il suo risultato in generale il
1481 valore di \var{errno} non è significativo, eccetto il caso in cui si sia
1482 ricevuto un errore di \const{EAI\_SYSTEM}, nel qual caso l'errore
1483 corrispondente è riportato tramite \var{errno}.
1488 \begin{tabular}[c]{|l|p{10cm}|}
1490 \textbf{Costante} & \textbf{Significato} \\
1493 \constd{EAI\_FAMILY} & La famiglia di indirizzi richiesta non è
1495 \constd{EAI\_SOCKTYPE}& Il tipo di socket richiesto non è supportato. \\
1496 \constd{EAI\_BADFLAGS}& Il campo \var{ai\_flags} contiene dei valori non
1498 \constd{EAI\_NONAME} & Il nome a dominio o il servizio non sono noti,
1499 viene usato questo errore anche quando si specifica
1500 il valore \val{NULL} per entrambi gli argomenti
1501 \param{node} e \param{service}. \\
1502 \constd{EAI\_SERVICE} & Il servizio richiesto non è disponibile per il tipo
1503 di socket richiesto, anche se può esistere per
1504 altri tipi di socket. \\
1505 \constd{EAI\_ADDRFAMILY}& La rete richiesta non ha nessun indirizzo di rete
1506 per la famiglia di indirizzi specificata. \\
1507 \constd{EAI\_NODATA} & La macchina specificata esiste, ma non ha nessun
1508 indirizzo di rete definito. \\
1509 \constd{EAI\_MEMORY} & È stato impossibile allocare la memoria necessaria
1511 \constd{EAI\_FAIL} & Il DNS ha restituito un errore di risoluzione
1513 \constd{EAI\_AGAIN} & Il DNS ha restituito un errore di risoluzione
1514 temporaneo, si può ritentare in seguito. \\
1515 \constd{EAI\_SYSTEM} & C'è stato un errore di sistema, si può controllare
1516 \var{errno} per i dettagli. \\
1518 % TODO estensioni GNU, trovarne la documentazione
1519 % \constd{EAI\_INPROGRESS}& Richiesta in corso. \\
1520 % \constd{EAI\_CANCELED}& La richiesta è stata cancellata.\\
1521 % \constd{EAI\_NOTCANCELED}& La richiesta non è stata cancellata. \\
1522 % \constd{EAI\_ALLDONE} & Tutte le richieste sono complete. \\
1523 % \constd{EAI\_INTR} & Richiesta interrotta. \\
1526 \caption{Costanti associate ai valori dei codici di errore della funzione
1527 \func{getaddrinfo}.}
1528 \label{tab:addrinfo_error_code}
1531 Come per i codici di errore di \func{gethostbyname} anche in questo caso è
1532 fornita una apposita funzione, analoga di \func{strerror}, che consente di
1533 utilizzarli direttamente per stampare a video un messaggio esplicativo; la
1534 funzione è \funcd{gai\_strerror} ed il suo prototipo è:
1538 \funcdecl{const char *gai\_strerror(int errcode)}
1540 Fornisce il messaggio corrispondente ad un errore di \func{getaddrinfo}.
1542 \bodydesc{La funzione restituisce il puntatore alla stringa contenente il
1543 messaggio di errore.}
1546 La funzione restituisce un puntatore alla stringa contenente il messaggio
1547 corrispondente dal codice di errore \param{errcode} ottenuto come valore di
1548 ritorno di \func{getaddrinfo}. La stringa è allocata staticamente, ma essendo
1549 costante, ed accessibile in sola lettura, questo non comporta nessun problema
1550 di rientranza della funzione.
1552 Dato che ad un certo nome a dominio possono corrispondere più indirizzi IP
1553 (sia IPv4 che IPv6), e che un certo servizio può essere fornito su protocolli
1554 e tipi di socket diversi, in generale, a meno di non aver eseguito una
1555 selezione specifica attraverso l'uso di \param{hints}, si otterrà una diversa
1556 struttura \struct{addrinfo} per ciascuna possibilità. Ad esempio se si
1557 richiede la risoluzione del servizio \textit{echo} per l'indirizzo
1558 \texttt{www.truelite.it}, e si imposta \const{AI\_CANONNAME} per avere anche
1559 la risoluzione del nome canonico, si avrà come risposta della funzione la
1560 lista illustrata in fig.~\ref{fig:sock_addrinfo_list}.
1562 \begin{figure}[!htb]
1564 \includegraphics[width=10cm]{img/addrinfo_list}
1565 \caption{La \textit{linked list} delle strutture \struct{addrinfo}
1566 restituite da \func{getaddrinfo}.}
1567 \label{fig:sock_addrinfo_list}
1570 Come primo esempio di uso di \func{getaddrinfo} vediamo un programma
1571 elementare di interrogazione del \textit{resolver} basato questa funzione, il
1572 cui corpo principale è riportato in fig.~\ref{fig:mygetaddr_example}. Il
1573 codice completo del programma, compresa la gestione delle opzioni in cui è
1574 gestita l'eventuale inizializzazione dell'argomento \var{hints} per
1575 restringere le ricerche su protocolli, tipi di socket o famiglie di indirizzi,
1576 è disponibile nel file \texttt{mygetaddr.c} dei sorgenti allegati alla guida.
1578 \begin{figure}[!htbp]
1579 \footnotesize \centering
1580 \begin{minipage}[c]{\codesamplewidth}
1581 \includecodesample{listati/mygetaddr.c}
1584 \caption{Esempio di codice per la risoluzione di un indirizzo.}
1585 \label{fig:mygetaddr_example}
1588 Il corpo principale inizia controllando (\texttt{\small 1--5}) il numero di
1589 argomenti passati, che devono essere sempre due, e corrispondere
1590 rispettivamente all'indirizzo ed al nome del servizio da risolvere. A questo
1591 segue la chiamata (\texttt{\small 7}) alla funzione \func{getaddrinfo}, ed il
1592 successivo controllo (\texttt{\small 8--11}) del suo corretto funzionamento,
1593 senza il quale si esce immediatamente stampando il relativo codice di errore.
1595 Se la funzione ha restituito un valore nullo il programma prosegue
1596 inizializzando (\texttt{\small 12}) il puntatore \var{ptr} che sarà usato nel
1597 successivo ciclo (\texttt{\small 14--35}) di scansione della lista delle
1598 strutture \struct{addrinfo} restituite dalla funzione. Prima di eseguire
1599 questa scansione (\texttt{\small 12}) viene stampato il valore del nome
1600 canonico che è presente solo nella prima struttura.
1602 La scansione viene ripetuta (\texttt{\small 14}) fintanto che si ha un
1603 puntatore valido. La selezione principale è fatta sul campo \var{ai\_family},
1604 che stabilisce a quale famiglia di indirizzi fa riferimento la struttura in
1605 esame. Le possibilità sono due, un indirizzo IPv4 o IPv6, se nessuna delle due
1606 si verifica si provvede (\texttt{\small 27--30}) a stampare un messaggio di
1607 errore ed uscire.\footnote{questa eventualità non dovrebbe mai verificarsi,
1608 almeno fintanto che la funzione \func{getaddrinfo} lavora correttamente.}
1610 Per ciascuno delle due possibili famiglie di indirizzi si estraggono le
1611 informazioni che poi verranno stampate alla fine del ciclo (\texttt{\small
1612 31--34}). Il primo caso esaminato (\texttt{\small 15--21}) è quello degli
1613 indirizzi IPv4, nel qual caso prima se ne stampa l'identificazione
1614 (\texttt{\small 16}) poi si provvede a ricavare la struttura degli indirizzi
1615 (\texttt{\small 17}) indirizzata dal campo \var{ai\_addr}, eseguendo un
1616 opportuno casting del puntatore per poter estrarre da questa la porta
1617 (\texttt{\small 18}) e poi l'indirizzo (\texttt{\small 19}) che verrà
1618 convertito con una chiamata ad \func{inet\_ntop}.
1620 La stessa operazione (\texttt{\small 21--27}) viene ripetuta per gli indirizzi
1621 IPv6, usando la rispettiva struttura degli indirizzi. Si noti anche come in
1622 entrambi i casi per la chiamata a \func{inet\_ntop} si sia dovuto passare il
1623 puntatore al campo contenente l'indirizzo IP nella struttura puntata dal campo
1624 \var{ai\_addr}.\footnote{il meccanismo è complesso a causa del fatto che al
1625 contrario di IPv4, in cui l'indirizzo IP può essere espresso con un semplice
1626 numero intero, in IPv6 questo deve essere necessariamente fornito come
1627 struttura, e pertanto anche se nella struttura puntata da \var{ai\_addr}
1628 sono presenti direttamente i valori finali, per l'uso con \func{inet\_ntop}
1629 occorre comunque passare un puntatore agli stessi (ed il costrutto
1630 \code{\&addr6->sin6\_addr} è corretto in quanto l'operatore \texttt{->} ha
1631 on questo caso precedenza su \texttt{\&}).}
1633 Una volta estratte dalla struttura \struct{addrinfo} tutte le informazioni
1634 relative alla risoluzione richiesta e stampati i relativi valori, l'ultimo
1635 passo (\texttt{\small 34}) è di estrarre da \var{ai\_next} l'indirizzo della
1636 eventuale successiva struttura presente nella lista e ripetere il ciclo, fin
1637 tanto che, completata la scansione, questo avrà un valore nullo e si potrà
1638 terminare (\texttt{\small 36}) il programma.
1640 Si tenga presente che \func{getaddrinfo} non garantisce nessun particolare
1641 ordinamento della lista delle strutture \struct{addrinfo} restituite, anche se
1642 usualmente i vari indirizzi IP (se ne è presente più di uno) sono forniti
1643 nello stesso ordine in cui vengono inviati dal server DNS. In particolare
1644 nulla garantisce che vengano forniti prima i dati relativi ai servizi di un
1645 determinato protocollo o tipo di socket, se ne sono presenti di diversi. Se
1646 allora utilizziamo il nostro programma potremo verificare il risultato:
1648 [piccardi@gont sources]$ ./mygetaddr -c gapil.truelite.it echo
1649 Canonical name sources2.truelite.it
1651 Indirizzo 62.48.34.25
1655 Indirizzo 62.48.34.25
1661 Una volta estratti i risultati dalla \textit{linked list} puntata
1662 da \param{res} se questa non viene più utilizzata si dovrà avere cura di
1663 disallocare opportunamente tutta la memoria, per questo viene fornita
1664 l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
1668 \funcdecl{void freeaddrinfo(struct addrinfo *res)}
1670 Libera la memoria allocata da una precedente chiamata a \func{getaddrinfo}.
1672 \bodydesc{La funzione non restituisce nessun codice di errore.}
1675 La funzione prende come unico argomento il puntatore \param{res}, ottenuto da
1676 una precedente chiamata a \func{getaddrinfo}, e scandisce la lista delle
1677 strutture per liberare tutta la memoria allocata. Dato che la funzione non ha
1678 valori di ritorno deve essere posta molta cura nel passare un valore valido
1681 Si tenga presente infine che se si copiano i risultati da una delle strutture
1682 \struct{addrinfo} restituite nella lista indicizzata da \param{res}, occorre
1683 avere cura di eseguire una \textit{deep copy} in cui si copiano anche tutti i
1684 dati presenti agli indirizzi contenuti nella struttura \struct{addrinfo},
1685 perché una volta disallocati i dati con \func{freeaddrinfo} questi non
1686 sarebbero più disponibili.
1688 Anche la nuova interfaccia definita da POSIX prevede una nuova funzione per
1689 eseguire la risoluzione inversa e determinare nomi di servizi e di dominio
1690 dati i rispettivi valori numerici. La funzione che sostituisce le varie
1691 \func{gethostbyname}, \func{getipnodebyname} e \func{getservbyname} è
1692 \funcd{getnameinfo}, ed il suo prototipo è:
1694 \headdecl{sys/socket.h}
1697 \funcdecl{int getnameinfo(const struct sockaddr *sa, socklen\_t salen, char
1698 *host, size\_t hostlen, char *serv, size\_t servlen, int flags)}
1700 Risolve il contenuto di una struttura degli indirizzi in maniera
1701 indipendente dal protocollo.
1703 \bodydesc{La funzione restituisce 0 in caso di successo e un codice di
1704 errore diverso da zero altrimenti.}
1707 La principale caratteristica di \func{getnameinfo} è che la funzione è in
1708 grado di eseguire una risoluzione inversa in maniera indipendente dal
1709 protocollo; il suo primo argomento \param{sa} infatti è il puntatore ad una
1710 struttura degli indirizzi generica, che può contenere sia indirizzi IPv4 che
1711 IPv6, la cui dimensione deve comunque essere specificata con l'argomento
1714 I risultati della funzione saranno restituiti nelle due stringhe puntate da
1715 \param{host} e \param{serv}, che dovranno essere state precedentemente
1716 allocate per una lunghezza massima che deve essere specificata con gli altri
1717 due argomenti \param{hostlen} e \param{servlen}. Si può, quando non si è
1718 interessati ad uno dei due, passare il valore \val{NULL} come argomento,
1719 così che la corrispondente informazione non verrà richiesta. Infine l'ultimo
1720 argomento \param{flags} è una maschera binaria i cui bit consentono di
1721 impostare le modalità con cui viene eseguita la ricerca, e deve essere
1722 specificato attraverso l'OR aritmetico dei valori illustrati in
1723 tab.~\ref{tab:getnameinfo_flags}.
1728 \begin{tabular}[c]{|l|p{10cm}|}
1730 \textbf{Costante} & \textbf{Significato} \\
1733 \constd{NI\_NOFQDN} & Richiede che venga restituita solo il nome della
1734 macchina all'interno del dominio al posto del
1735 nome completo (FQDN).\\
1736 \constd{NI\_NUMERICHOST}& Richiede che venga restituita la forma numerica
1737 dell'indirizzo (questo succede sempre se il nome
1738 non può essere ottenuto).\\
1739 \constd{NI\_NAMEREQD} & Richiede la restituzione di un errore se il nome
1740 non può essere risolto.\\
1741 \constd{NI\_NUMERICSERV}& Richiede che il servizio venga restituito in
1742 forma numerica (attraverso il numero di porta).\\
1743 \constd{NI\_DGRAM} & Richiede che venga restituito il nome del
1744 servizio su UDP invece che quello su TCP per quei
1745 pichi servizi (porte 512-214) che soni diversi
1746 nei due protocolli.\\
1749 \caption{Costanti associate ai bit dell'argomento \param{flags} della
1750 funzione \func{getnameinfo}.}
1751 \label{tab:getnameinfo_flags}
1754 La funzione ritorna zero in caso di successo, e scrive i propri risultati agli
1755 indirizzi indicati dagli argomenti \param{host} e \param{serv} come stringhe
1756 terminate dal carattere NUL, a meno che queste non debbano essere troncate
1757 qualora la loro dimensione ecceda quelle specificate dagli argomenti
1758 \param{hostlen} e \param{servlen}. Sono comunque definite le due costanti
1759 \constd{NI\_MAXHOST} e \constd{NI\_MAXSERV}\footnote{in Linux le due costanti
1760 sono definite in \headfile{netdb.h} ed hanno rispettivamente il valore 1024
1761 e 12.} che possono essere utilizzate come limiti massimi. In caso di
1762 errore viene restituito invece un codice che assume gli stessi valori
1763 illustrati in tab.~\ref{tab:addrinfo_error_code}.
1765 A questo punto possiamo fornire degli esempi di utilizzo della nuova
1766 interfaccia, adottandola per le precedenti implementazioni del client e del
1767 server per il servizio \textit{echo}; dato che l'uso delle funzioni appena
1768 illustrate (in particolare di \func{getaddrinfo}) è piuttosto complesso,
1769 essendo necessaria anche una impostazione diretta dei campi dell'argomento
1770 \param{hints}, provvederemo una interfaccia semplificata per i due casi visti
1771 finora, quello in cui si specifica nel client un indirizzo remoto per la
1772 connessione al server, e quello in cui si specifica nel server un indirizzo
1773 locale su cui porsi in ascolto.
1775 La prima funzione della nostra interfaccia semplificata è \texttt{sockconn}
1776 che permette di ottenere un socket, connesso all'indirizzo ed al servizio
1777 specificati. Il corpo della funzione è riportato in
1778 fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
1779 dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
1782 \begin{figure}[!htbp]
1783 \footnotesize \centering
1784 \begin{minipage}[c]{\codesamplewidth}
1785 \includecodesample{listati/sockconn.c}
1788 \caption{Il codice della funzione \texttt{sockconn}.}
1789 \label{fig:sockconn_code}
1792 La funzione prende quattro argomenti, i primi due sono le stringhe che
1793 indicano il nome della macchina a cui collegarsi ed il relativo servizio su
1794 cui sarà effettuata la risoluzione; seguono il protocollo da usare (da
1795 specificare con il valore numerico di \conffile{/etc/protocols}) ed il tipo di
1796 socket (al solito specificato con i valori illustrati in
1797 sez.~\ref{sec:sock_type}). La funzione ritorna il valore del file descriptor
1798 associato al socket (un numero positivo) in caso di successo, o -1 in caso di
1799 errore; per risolvere il problema di non poter passare indietro i valori di
1800 ritorno di \func{getaddrinfo} contenenti i relativi codici di
1801 errore\footnote{non si può avere nessuna certezza che detti valori siano
1802 negativi, è questo è invece necessario per evitare ogni possibile ambiguità
1803 nei confronti del valore di ritorno in caso di successo.} si sono stampati i
1804 messaggi d'errore direttamente nella funzione.
1806 Una volta definite le variabili necessarie (\texttt{\small 3--5}) la funzione
1807 prima (\texttt{\small 6}) azzera il contenuto della struttura \var{hint} e poi
1808 provvede (\texttt{\small 7--9}) ad inizializzarne i valori necessari per la
1809 chiamata (\texttt{\small 10}) a \func{getaddrinfo}. Di quest'ultima si
1810 controlla (\texttt{\small 12--16}) il codice di ritorno, in modo da stampare un
1811 avviso di errore, azzerare \var{errno} ed uscire in caso di errore. Dato che
1812 ad una macchina possono corrispondere più indirizzi IP, e di tipo diverso (sia
1813 IPv4 che IPv6), mentre il servizio può essere in ascolto soltanto su uno solo
1814 di questi, si provvede a tentare la connessione per ciascun indirizzo
1815 restituito all'interno di un ciclo (\texttt{\small 18--40}) di scansione della
1816 lista restituita da \func{getaddrinfo}, ma prima (\texttt{\small 17}) si salva
1817 il valore del puntatore per poterlo riutilizzare alla fine per disallocare la
1820 Il ciclo viene ripetuto (\texttt{\small 18}) fintanto che si hanno indirizzi
1821 validi, ed inizia (\texttt{\small 19}) con l'apertura del socket; se questa
1822 fallisce si controlla (\texttt{\small 20}) se sono disponibili altri
1823 indirizzi, nel qual caso si passa al successivo (\texttt{\small 21}) e si
1824 riprende (\texttt{\small 22}) il ciclo da capo; se non ve ne sono si stampa
1825 l'errore ritornando immediatamente (\texttt{\small 24--27}). Quando la
1826 creazione del socket ha avuto successo si procede (\texttt{\small 29})
1827 direttamente con la connessione, di nuovo in caso di fallimento viene ripetuto
1828 (\texttt{\small 30--38}) il controllo se vi sono o no altri indirizzi da
1829 provare nella stessa modalità fatta in precedenza, aggiungendovi però in
1830 entrambi i casi (\texttt{\small 32} e (\texttt{\small 36}) la chiusura del
1831 socket precedentemente aperto, che non è più utilizzabile.
1833 Se la connessione ha avuto successo invece si termina (\texttt{\small 39})
1834 direttamente il ciclo, e prima di ritornare (\texttt{\small 31}) il valore del
1835 file descriptor del socket si provvede (\texttt{\small 30}) a liberare le
1836 strutture \struct{addrinfo} allocate da \func{getaddrinfo} utilizzando il
1837 valore del relativo puntatore precedentemente (\texttt{\small 17}) salvato.
1838 Si noti come per la funzione sia del tutto irrilevante se la struttura
1839 ritornata contiene indirizzi IPv6 o IPv4, in quanto si fa uso direttamente dei
1840 dati relativi alle strutture degli indirizzi di \struct{addrinfo} che sono
1841 opachi rispetto all'uso della funzione \func{connect}.
1843 \begin{figure}[!htbp]
1844 \footnotesize \centering
1845 \begin{minipage}[c]{\codesamplewidth}
1846 \includecodesample{listati/TCP_echo_fifth.c}
1849 \caption{Il nuovo codice per la connessione del client \textit{echo}.}
1850 \label{fig:TCP_echo_fifth}
1853 Per usare questa funzione possiamo allora modificare ulteriormente il nostro
1854 programma client per il servizio \textit{echo}; in questo caso rispetto al
1855 codice usato finora per collegarsi (vedi fig.~\ref{fig:TCP_echo_client_1})
1856 avremo una semplificazione per cui il corpo principale del nostro client
1857 diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
1858 chiamate a \func{socket}, \func{inet\_pton} e \func{connect} sono sostituite
1859 da una singola chiamata a \texttt{sockconn}. Inoltre il nuovo client (il cui
1860 codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
1861 consente di utilizzare come argomento del programma un nome a dominio al posto
1862 dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
1864 \begin{figure}[!htbp]
1865 \footnotesize \centering
1866 \begin{minipage}[c]{\codesamplewidth}
1867 \includecodesample{listati/sockbind.c}
1870 \caption{Il codice della funzione \texttt{sockbind}.}
1871 \label{fig:sockbind_code}
1874 La seconda funzione di ausilio è \texttt{sockbind}, il cui corpo principale è
1875 riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
1876 nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
1877 notare la funzione è del tutto analoga alla precedente \texttt{sockconn}, e
1878 prende gli stessi argomenti, però invece di eseguire una connessione con
1879 \func{connect} si limita a chiamare \func{bind} per collegare il socket ad una
1882 Dato che la funzione è pensata per essere utilizzata da un server ci si può
1883 chiedere a quale scopo mantenere l'argomento \param{host} quando l'indirizzo
1884 di questo è usualmente noto. Si ricordi però quanto detto in
1885 sez.~\ref{sec:TCP_func_bind}, relativamente al significato della scelta di un
1886 indirizzo specifico come argomento di \func{bind}, che consente di porre il
1887 server in ascolto su uno solo dei possibili diversi indirizzi presenti su di
1888 una macchina. Se non si vuole che la funzione esegua \func{bind} su un
1889 indirizzo specifico, ma utilizzi l'indirizzo generico, occorrerà avere cura di
1890 passare un valore \val{NULL} come valore per l'argomento \var{host}; l'uso
1891 del valore \const{AI\_PASSIVE} serve ad ottenere il valore generico nella
1892 rispettiva struttura degli indirizzi.
1894 Come già detto la funzione è analoga a \texttt{sockconn} ed inizia azzerando
1895 ed inizializzando (\texttt{\small 6--11}) opportunamente la struttura
1896 \var{hint} con i valori ricevuti come argomenti, soltanto che in questo caso
1897 si è usata (\texttt{\small 8}) una impostazione specifica dei flag di
1898 \var{hint} usando \const{AI\_PASSIVE} per indicare che il socket sarà usato
1899 per una apertura passiva. Per il resto la chiamata (\texttt{\small 12--18}) a
1900 \func{getaddrinfo} e ed il ciclo principale (\texttt{\small 20--42}) sono
1901 identici, solo che si è sostituita (\texttt{\small 31}) la chiamata a
1902 \func{connect} con una chiamata a \func{bind}. Anche la conclusione
1903 (\texttt{\small 43--44}) della funzione è identica.
1905 Si noti come anche in questo caso si siano inserite le stampe degli errori
1906 sullo standard error, nonostante la funzione possa essere invocata da un
1907 demone. Nel nostro caso questo non è un problema in quanto se la funzione non
1908 ha successo il programma deve uscire immediatamente prima di essere posto in
1909 background, e può quindi scrivere gli errori direttamente sullo standard
1912 \begin{figure}[!htbp]
1913 \footnotesize \centering
1914 \begin{minipage}[c]{\codesamplewidth}
1915 \includecodesample{listati/TCP_echod_third.c}
1918 \caption{Nuovo codice per l'apertura passiva del server \textit{echo}.}
1919 \label{fig:TCP_echod_third}
1922 Con l'uso di questa funzione si può modificare anche il codice del nostro
1923 server \textit{echo}, che rispetto a quanto illustrato nella versione iniziale
1924 di fig.~\ref{fig:TCP_echo_server_first_code} viene modificato nella forma
1925 riportata in fig.~\ref{fig:TCP_echod_third}. In questo caso il socket su cui
1926 porsi in ascolto viene ottenuto (\texttt{\small 15--18}) da \texttt{sockbind}
1927 che si cura anche della eventuale risoluzione di un indirizzo specifico sul
1928 quale si voglia far ascoltare il server.
1932 \section{Le opzioni dei socket}
1933 \label{sec:sock_options}
1935 Benché dal punto di vista del loro uso come canali di trasmissione di dati i
1936 socket siano trattati allo stesso modo dei file, ed acceduti tramite i file
1937 descriptor, la normale interfaccia usata per la gestione dei file non è
1938 sufficiente a poterne controllare tutte le caratteristiche, che variano tra
1939 l'altro a seconda del loro tipo (e della relativa forma di comunicazione
1940 sottostante). In questa sezione vedremo allora quali sono le funzioni dedicate
1941 alla gestione delle caratteristiche specifiche dei vari tipi di socket, le
1942 cosiddette \textit{socket options}.
1945 \subsection{Le funzioni \func{setsockopt} e \func{getsockopt}}
1946 \label{sec:sock_setsockopt}
1948 Le varie caratteristiche dei socket possono essere gestite attraverso l'uso di
1949 due funzioni generiche che permettono rispettivamente di impostarle e di
1950 recuperarne il valore corrente. La prima di queste due funzioni, quella usata
1951 per impostare le \textit{socket options}, è \funcd{setsockopt}, ed il suo
1954 \headdecl{sys/socket.h}
1955 \headdecl{sys/types.h}
1957 \funcdecl{int setsockopt(int sock, int level, int optname, const void
1958 *optval, socklen\_t optlen)}
1959 Imposta le opzioni di un socket.
1961 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1962 errore, nel qual caso \var{errno} assumerà i valori:
1964 \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
1965 \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
1966 \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
1967 \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
1969 \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
1976 Il primo argomento della funzione, \param{sock}, indica il socket su cui si
1977 intende operare; per indicare l'opzione da impostare si devono usare i due
1978 argomenti successivi, \param{level} e \param{optname}. Come abbiamo visto in
1979 sez.~\ref{sec:net_protocols} i protocolli di rete sono strutturati su vari
1980 livelli, ed l'interfaccia dei socket può usarne più di uno. Si avranno allora
1981 funzionalità e caratteristiche diverse per ciascun protocollo usato da un
1982 socket, e quindi saranno anche diverse le opzioni che si potranno impostare
1983 per ciascun socket, a seconda del \textsl{livello} (trasporto, rete, ecc.) su
1984 cui si vuole andare ad operare.
1986 Il valore di \param{level} seleziona allora il protocollo su cui vuole
1987 intervenire, mentre \param{optname} permette di scegliere su quale delle
1988 opzioni che sono definite per quel protocollo si vuole operare. In sostanza la
1989 selezione di una specifica opzione viene fatta attraverso una coppia di valori
1990 \param{level} e \param{optname} e chiaramente la funzione avrà successo
1991 soltanto se il protocollo in questione prevede quella opzione ed è utilizzato
1992 dal socket. Infine \param{level} prevede anche il valore speciale
1993 \const{SOL\_SOCKET} usato per le opzioni generiche che sono disponibili per
1994 qualunque tipo di socket.
1996 I valori usati per \param{level}, corrispondenti ad un dato protocollo usato
1997 da un socket, sono quelli corrispondenti al valore numerico che identifica il
1998 suddetto protocollo in \conffile{/etc/protocols}; dato che la leggibilità di un
1999 programma non trarrebbe certo beneficio dall'uso diretto dei valori numerici,
2000 più comunemente si indica il protocollo tramite le apposite costanti
2001 \texttt{SOL\_*} riportate in tab.~\ref{tab:sock_option_levels}, dove si sono
2002 riassunti i valori che possono essere usati per l'argomento
2003 \param{level}.\footnote{la notazione in questo caso è, purtroppo, abbastanza
2004 confusa: infatti in Linux il valore si può impostare sia usando le costanti
2005 \texttt{SOL\_*}, che le analoghe \texttt{IPPROTO\_*} (citate anche da
2006 Stevens in \cite{UNP1}); entrambe hanno gli stessi valori che sono
2007 equivalenti ai numeri di protocollo di \conffile{/etc/protocols}, con una
2008 eccezione specifica, che è quella del protocollo ICMP, per la quale non
2009 esista una costante, il che è comprensibile dato che il suo valore, 1, è
2010 quello che viene assegnato a \const{SOL\_SOCKET}.}
2015 \begin{tabular}[c]{|l|l|}
2017 \textbf{Livello} & \textbf{Significato} \\
2020 \constd{SOL\_SOCKET}& Opzioni generiche dei socket.\\
2021 \constd{SOL\_IP} & Opzioni specifiche per i socket che usano IPv4.\\
2022 \constd{SOL\_TCP} & Opzioni per i socket che usano TCP.\\
2023 \constd{SOL\_IPV6} & Opzioni specifiche per i socket che usano IPv6.\\
2024 \constd{SOL\_ICMPV6}& Opzioni specifiche per i socket che usano ICMPv6.\\
2027 \caption{Possibili valori dell'argomento \param{level} delle
2028 funzioni \func{setsockopt} e \func{getsockopt}.}
2029 \label{tab:sock_option_levels}
2032 Il quarto argomento, \param{optval} è un puntatore ad una zona di memoria che
2033 contiene i dati che specificano il valore dell'opzione che si vuole passare al
2034 socket, mentre l'ultimo argomento \param{optlen},\footnote{questo argomento è
2035 in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
2036 \acr{libc5}; l'uso di \type{socklen\_t} è stato introdotto da POSIX (valgono
2037 le stesse considerazioni per l'uso di questo tipo di dato fatte in
2038 sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
2039 dimensione in byte dei dati presenti all'indirizzo indicato da \param{optval}.
2040 Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
2041 individuare qual è quello che deve essere usato, ed utilizzare le opportune
2044 La gran parte delle opzioni utilizzano per \param{optval} un valore intero, se
2045 poi l'opzione esprime una condizione logica, il valore è sempre un intero, ma
2046 si dovrà usare un valore non nullo per abilitarla ed un valore nullo per
2047 disabilitarla. Se invece l'opzione non prevede di dover ricevere nessun tipo
2048 di valore si deve impostare \param{optval} a \val{NULL}. Un piccolo numero
2049 di opzioni però usano dei tipi di dati peculiari, è questo il motivo per cui
2050 \param{optval} è stato definito come puntatore generico.
2052 La seconda funzione usata per controllare le proprietà dei socket è
2053 \funcd{getsockopt}, che serve a leggere i valori delle opzioni dei socket ed a
2054 farsi restituire i dati relativi al loro funzionamento; il suo prototipo è:
2056 \headdecl{sys/socket.h}
2057 \headdecl{sys/types.h}
2059 \funcdecl{int getsockopt(int s, int level, int optname, void *optval,
2060 socklen\_t *optlen)} Legge le opzioni di un socket.
2062 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2063 errore, nel qual caso \var{errno} assumerà i valori:
2065 \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
2066 \item[\errcode{EFAULT}] l'indirizzo \param{optval} o quello di
2067 \param{optlen} non è valido.
2068 \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
2070 \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
2076 I primi tre argomenti sono identici ed hanno lo stesso significato di quelli
2077 di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
2078 per entrambe le funzioni. In questo caso \param{optval} viene usato per
2079 ricevere le informazioni ed indica l'indirizzo a cui andranno scritti i dati
2080 letti dal socket, infine \param{optlen} diventa un puntatore ad una variabile
2081 che viene usata come \textit{value result argument} per indicare, prima della
2082 chiamata della funzione, la lunghezza del buffer allocato per \param{optval} e
2083 per ricevere indietro, dopo la chiamata della funzione, la dimensione
2084 effettiva dei dati scritti su di esso. Se la dimensione del buffer allocato
2085 per \param{optval} non è sufficiente si avrà un errore.
2089 \subsection{Le opzioni generiche}
2090 \label{sec:sock_generic_options}
2092 Come accennato esiste un insieme generico di opzioni dei socket che possono
2093 applicarsi a qualunque tipo di socket,\footnote{una descrizione di queste
2094 opzioni è generalmente disponibile nella settima sezione delle pagine di
2095 manuale, nel caso specifico la si può consultare con \texttt{man 7 socket}.}
2096 indipendentemente da quale protocollo venga poi utilizzato. Se si vuole
2097 operare su queste opzioni generiche il livello da utilizzare è
2098 \const{SOL\_SOCKET}; si è riportato un elenco di queste opzioni in
2099 tab.~\ref{tab:sock_opt_socklevel}.
2105 \begin{tabular}[c]{|l|c|c|c|l|l|}
2107 \textbf{Opzione}&\texttt{get}&\texttt{set}&\textbf{flag}&\textbf{Tipo}&
2108 \textbf{Descrizione}\\
2111 \const{SO\_KEEPALIVE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2112 Controlla l'attività della connessione.\\
2113 \const{SO\_OOBINLINE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2114 Lascia in linea i dati \textit{out-of-band}.\\
2115 \const{SO\_RCVLOWAT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2116 Basso livello sul buffer di ricezione.\\
2117 \const{SO\_SNDLOWAT} &$\bullet$&$\bullet$& &\texttt{int}&
2118 Basso livello sul buffer di trasmissione.\\
2119 \const{SO\_RCVTIMEO} &$\bullet$&$\bullet$& &\texttt{timeval}&
2120 Timeout in ricezione.\\
2121 \const{SO\_SNDTIMEO} &$\bullet$&$\bullet$& &\texttt{timeval}&
2122 Timeout in trasmissione.\\
2123 \const{SO\_BSDCOMPAT}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2124 Abilita la compatibilità con BSD.\\
2125 \const{SO\_PASSCRED} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2126 Abilita la ricezione di credenziali.\\
2127 \const{SO\_PEERCRED} &$\bullet$& & &\texttt{ucred}&
2128 Restituisce le credenziali del processo remoto.\\
2129 \const{SO\_BINDTODEVICE}&$\bullet$&$\bullet$& &\texttt{char *}&
2130 Lega il socket ad un dispositivo.\\
2131 \const{SO\_DEBUG} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2132 Abilita il debugging sul socket.\\
2133 \const{SO\_REUSEADDR}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2134 Consente il riutilizzo di un indirizzo locale.\\
2135 \const{SO\_TYPE} &$\bullet$& & &\texttt{int}&
2136 Restituisce il tipo di socket.\\
2137 \const{SO\_ACCEPTCONN}&$\bullet$& & &\texttt{int}&
2138 Indica se il socket è in ascolto.\\
2139 \const{SO\_DONTROUTE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2140 Non invia attraverso un gateway.\\
2141 \const{SO\_BROADCAST}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2142 Attiva o disattiva il \textit{broadcast}.\\
2143 \const{SO\_SNDBUF} &$\bullet$&$\bullet$& &\texttt{int}&
2144 Imposta dimensione del buffer di trasmissione.\\
2145 \const{SO\_RCVBUF} &$\bullet$&$\bullet$& &\texttt{int}&
2146 Imposta dimensione del buffer di ricezione.\\
2147 \const{SO\_LINGER} &$\bullet$&$\bullet$& &\texttt{linger}&
2148 Indugia nella chiusura con dati da spedire.\\
2149 \const{SO\_PRIORITY} &$\bullet$&$\bullet$& &\texttt{int}&
2150 Imposta la priorità del socket.\\
2151 \const{SO\_ERROR} &$\bullet$& & &\texttt{int}&
2152 Riceve e cancella gli errori pendenti.\\
2155 \caption{Le opzioni disponibili al livello \const{SOL\_SOCKET}.}
2156 \label{tab:sock_opt_socklevel}
2159 % TODO aggiungere e documentare SO_ATTACH_BPF, introdotta con il kernel 3.19,
2160 % vedi http://lwn.net/Articles/625224/
2161 % TODO aggiungere e documentare SO_INCOMING_CPU, introdotta con il kernel 3.19,
2162 % vedi https://lwn.net/Articles/626150/
2164 La tabella elenca le costanti che identificano le singole opzioni da usare
2165 come valore per \param{optname}; le due colonne seguenti indicano per quali
2166 delle due funzioni (\func{getsockopt} o \func{setsockopt}) l'opzione è
2167 disponibile, mentre la colonna successiva indica, quando di ha a che fare con
2168 un valore di \param{optval} intero, se l'opzione è da considerare un numero o
2169 un valore logico. Si è inoltre riportato sulla quinta colonna il tipo di dato
2170 usato per \param{optval} ed una breve descrizione del significato delle
2171 singole opzioni sulla sesta.
2173 Le descrizioni delle opzioni presenti in tab.~\ref{tab:sock_opt_socklevel}
2174 sono estremamente sommarie, è perciò necessario fornire un po' più di
2175 informazioni. Alcune opzioni inoltre hanno una notevole rilevanza nella
2176 gestione dei socket, e pertanto il loro utilizzo sarà approfondito
2177 separatamente in sez.~\ref{sec:sock_options_main}. Quello che segue è quindi
2178 soltanto un elenco più dettagliato della breve descrizione di
2179 tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
2180 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
2182 \item[\const{SO\_KEEPALIVE}] questa opzione abilita un meccanismo di verifica
2183 della persistenza di una connessione associata al socket (ed è pertanto
2184 effettiva solo sui socket che supportano le connessioni, ed è usata
2185 principalmente con il TCP). L'opzione utilizza per \param{optval} un intero
2186 usato come valore logico. Maggiori dettagli sul suo funzionamento sono
2187 forniti in sez.~\ref{sec:sock_options_main}.
2189 \item[\constd{SO\_OOBINLINE}] se questa opzione viene abilitata i dati
2190 \textit{out-of-band} vengono inviati direttamente nel flusso di dati del
2191 socket (e sono quindi letti con una normale \func{read}) invece che restare
2192 disponibili solo per l'accesso con l'uso del flag \const{MSG\_OOB} di
2193 \func{recvmsg}. L'argomento è trattato in dettaglio in
2194 sez.~\ref{sec:TCP_urgent_data}. L'opzione funziona soltanto con socket che
2195 supportino i dati \textit{out-of-band} (non ha senso per socket UDP ad
2196 esempio), ed utilizza per \param{optval} un intero usato come valore logico.
2198 \item[\constd{SO\_RCVLOWAT}] questa opzione imposta il valore che indica il
2199 numero minimo di byte che devono essere presenti nel buffer di ricezione
2200 perché il kernel passi i dati all'utente, restituendoli ad una \func{read} o
2201 segnalando ad una \func{select} (vedi sez.~\ref{sec:TCP_sock_select}) che ci
2202 sono dati in ingresso. L'opzione utilizza per \param{optval} un intero che
2203 specifica il numero di byte, ma con Linux questo valore è sempre 1 e non può
2204 essere cambiato; \func{getsockopt} leggerà questo valore mentre
2205 \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
2207 \item[\constd{SO\_SNDLOWAT}] questa opzione imposta il valore che indica il
2208 numero minimo di byte che devono essere presenti nel buffer di trasmissione
2209 perché il kernel li invii al protocollo successivo, consentendo ad una
2210 \func{write} di ritornare o segnalando ad una \func{select} (vedi
2211 sez.~\ref{sec:TCP_sock_select}) che è possibile eseguire una scrittura.
2212 L'opzione utilizza per \param{optval} un intero che specifica il numero di
2213 byte, come per la precedente \const{SO\_RCVLOWAT} con Linux questo valore è
2214 sempre 1 e non può essere cambiato; \func{getsockopt} leggerà questo valore
2215 mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
2217 \item[\constd{SO\_RCVTIMEO}] l'opzione permette di impostare un tempo massimo
2218 sulle operazioni di lettura da un socket, e prende per \param{optval} una
2219 struttura di tipo \struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct})
2220 identica a quella usata con \func{select}. Con \func{getsockopt} si può
2221 leggere il valore attuale, mentre con \func{setsockopt} si imposta il tempo
2222 voluto, usando un valore nullo per \struct{timeval} il timeout viene
2225 Se l'opzione viene attivata tutte le volte che una delle funzioni di lettura
2226 (\func{read}, \func{readv}, \func{recv}, \func{recvfrom} e \func{recvmsg})
2227 si blocca in attesa di dati per un tempo maggiore di quello impostato, essa
2228 ritornerà un valore -1 e la variabile \var{errno} sarà impostata con un
2229 errore di \errcode{EAGAIN} e \errcode{EWOULDBLOCK}, così come sarebbe
2230 avvenuto se si fosse aperto il socket in modalità non bloccante.\footnote{in
2231 teoria, se il numero di byte presenti nel buffer di ricezione fosse
2232 inferiore a quello specificato da \const{SO\_RCVLOWAT}, l'effetto potrebbe
2233 essere semplicemente quello di provocare l'uscita delle funzioni di
2234 lettura restituendo il numero di byte fino ad allora ricevuti; dato che
2235 con Linux questo valore è sempre 1 questo caso non esiste.}
2237 In genere questa opzione non è molto utilizzata se si ha a che fare con la
2238 lettura dei dati, in quanto è sempre possibile usare una \func{select} che
2239 consente di specificare un \textit{timeout}; l'uso di \func{select} non
2240 consente però di impostare il timeout per l'uso di \func{connect}, per avere
2241 il quale si può ricorrere a questa opzione.
2243 % TODO verificare il timeout con un programma di test
2245 \item[\constd{SO\_SNDTIMEO}] l'opzione permette di impostare un tempo massimo
2246 sulle operazioni di scrittura su un socket, ed usa gli stessi valori di
2247 \const{SO\_RCVTIMEO}. In questo caso però si avrà un errore di
2248 \errcode{EAGAIN} o \errcode{EWOULDBLOCK} per le funzioni di scrittura
2249 \func{write}, \func{writev}, \func{send}, \func{sendto} e \func{sendmsg}
2250 qualora queste restino bloccate per un tempo maggiore di quello specificato.
2252 \item[\constd{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
2253 comportamento di BSD (in particolare ne riproduce i bug). Attualmente è una
2254 opzione usata solo per il protocollo UDP e ne è prevista la rimozione in
2255 futuro. L'opzione utilizza per \param{optval} un intero usato come valore
2258 Quando viene abilitata gli errori riportati da messaggi ICMP per un socket
2259 UDP non vengono passati al programma in user space. Con le versioni 2.0.x
2260 del kernel erano anche abilitate altre opzioni per i socket raw, che sono
2261 state rimosse con il passaggio al 2.2; è consigliato correggere i programmi
2262 piuttosto che usare questa funzione.
2264 \item[\constd{SO\_PASSCRED}] questa opzione abilita sui socket unix-domain
2265 (vedi sez.~\ref{sec:unix_socket}) la ricezione dei messaggi di controllo di
2266 tipo \const{SCM\_CREDENTIALS}. Prende come \param{optval} un intero usato
2269 \item[\constd{SO\_PEERCRED}] questa opzione restituisce le credenziali del
2270 processo remoto connesso al socket; l'opzione è disponibile solo per socket
2271 unix-domain e può essere usata solo con \func{getsockopt}. Utilizza per
2272 \param{optval} una apposita struttura \struct{ucred} (vedi
2273 sez.~\ref{sec:unix_socket}).
2275 \item[\constd{SO\_BINDTODEVICE}] questa opzione permette di \textsl{legare} il
2276 socket ad una particolare interfaccia, in modo che esso possa ricevere ed
2277 inviare pacchetti solo su quella. L'opzione richiede per \param{optval} il
2278 puntatore ad una stringa contenente il nome dell'interfaccia (ad esempio
2279 \texttt{eth0}); utilizzando una stringa nulla o un valore nullo per
2280 \param{optlen} si può rimuovere un precedente collegamento.
2282 Il nome della interfaccia deve essere specificato con una stringa terminata
2283 da uno zero e di lunghezza massima pari a \constd{IFNAMSIZ}; l'opzione è
2284 effettiva solo per alcuni tipi di socket, ed in particolare per quelli della
2285 famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
2286 socket} (vedi sez.~\ref{sec:socket_raw}).
2288 \item[\constd{SO\_DEBUG}] questa opzione abilita il debugging delle operazioni
2289 dei socket; l'opzione utilizza per \param{optval} un intero usato come
2290 valore logico, e può essere utilizzata solo da un processo con i privilegi
2291 di amministratore (in particolare con la \textit{capability}
2292 \const{CAP\_NET\_ADMIN}). L'opzione necessita inoltre dell'opportuno
2293 supporto nel kernel;\footnote{deve cioè essere definita la macro di
2294 preprocessore \macrod{SOCK\_DEBUGGING} nel file \file{include/net/sock.h}
2295 dei sorgenti del kernel, questo è sempre vero nei kernel delle serie
2296 superiori alla 2.3, per i kernel delle serie precedenti invece è
2297 necessario aggiungere a mano detta definizione; è inoltre possibile
2298 abilitare anche il tracciamento degli stati del TCP definendo la macro
2299 \macrod{STATE\_TRACE} in \file{include/net/tcp.h}.} quando viene
2300 abilitata una serie di messaggi con le informazioni di debug vengono inviati
2301 direttamente al sistema del kernel log.\footnote{si tenga presente che il
2302 comportamento è diverso da quanto avviene con BSD, dove l'opzione opera
2303 solo sui socket TCP, causando la scrittura di tutti i pacchetti inviati
2304 sulla rete su un buffer circolare che viene letto da un apposito
2305 programma, \cmd{trpt}.}
2307 \item[\const{SO\_REUSEADDR}] questa opzione permette di eseguire la funzione
2308 \func{bind} su indirizzi locali che siano già in uso da altri socket;
2309 l'opzione utilizza per \param{optval} un intero usato come valore logico.
2310 Questa opzione modifica il comportamento normale dell'interfaccia dei socket
2311 che fa fallire l'esecuzione della funzione \func{bind} con un errore di
2312 \errcode{EADDRINUSE} quando l'indirizzo locale\footnote{più propriamente il
2313 controllo viene eseguito sulla porta.} è già in uso da parte di un altro
2314 socket. Maggiori dettagli sul suo funzionamento sono forniti in
2315 sez.~\ref{sec:sock_options_main}.
2317 \item[\constd{SO\_TYPE}] questa opzione permette di leggere il tipo di socket
2318 su cui si opera; funziona solo con \func{getsockopt}, ed utilizza per
2319 \param{optval} un intero in cui verrà restituito il valore numerico che lo
2320 identifica (ad esempio \const{SOCK\_STREAM}).
2322 \item[\constd{SO\_ACCEPTCONN}] questa opzione permette di rilevare se il socket
2323 su cui opera è stato posto in modalità di ricezione di eventuali connessioni
2324 con una chiamata a \func{listen}. L'opzione può essere usata soltanto con
2325 \func{getsockopt} e utilizza per \param{optval} un intero in cui viene
2326 restituito 1 se il socket è in ascolto e 0 altrimenti.
2328 \item[\constd{SO\_DONTROUTE}] questa opzione forza l'invio diretto dei
2329 pacchetti del socket, saltando ogni processo relativo all'uso della tabella
2330 di routing del kernel. Prende per \param{optval} un intero usato come valore
2333 \item[\constd{SO\_BROADCAST}] questa opzione abilita il \textit{broadcast};
2334 quanto abilitata i socket di tipo \const{SOCK\_DGRAM} riceveranno i
2335 pacchetti inviati all'indirizzo di \textit{broadcast}, e potranno scrivere
2336 pacchetti su tale indirizzo. Prende per \param{optval} un intero usato come
2337 valore logico. L'opzione non ha effetti su un socket di tipo
2338 \const{SOCK\_STREAM}.
2340 \item[\constd{SO\_SNDBUF}] questa opzione imposta la dimensione del buffer di
2341 trasmissione del socket. Prende per \param{optval} un intero indicante il
2342 numero di byte. Il valore di default ed il valore massimo che si possono
2343 specificare come argomento per questa opzione sono impostabili
2344 rispettivamente tramite gli opportuni valori di \func{sysctl} (vedi
2345 sez.~\ref{sec:sock_sysctl}).
2347 \item[\constd{SO\_RCVBUF}] questa opzione imposta la dimensione del buffer di
2348 ricezione del socket. Prende per \param{optval} un intero indicante il
2349 numero di byte. Il valore di default ed il valore massimo che si può
2350 specificare come argomento per questa opzione sono impostabili tramiti gli
2351 opportuni valori di \func{sysctl} (vedi sez.~\ref{sec:sock_sysctl}).
2353 Si tenga presente che nel caso di socket TCP, per entrambe le opzioni
2354 \const{SO\_RCVBUF} e \const{SO\_SNDBUF}, il kernel alloca effettivamente una
2355 quantità di memoria doppia rispetto a quanto richiesto con
2356 \func{setsockopt}. Questo comporta che una successiva lettura con
2357 \func{getsockopt} riporterà un valore diverso da quello impostato con
2358 \func{setsockopt}. Questo avviene perché TCP necessita dello spazio in più
2359 per mantenere dati amministrativi e strutture interne, e solo una parte
2360 viene usata come buffer per i dati, mentre il valore letto da
2361 \func{getsockopt} e quello riportato nei vari parametri di
2362 \textit{sysctl}\footnote{cioè \sysctlrelfile{net/core}{wmem\_max} e
2363 \sysctlrelfile{net/core}{rmem\_max} in \texttt{/proc/sys/net/core} e
2364 \sysctlrelfile{net/ipv4}{tcp\_wmem} e \sysctlrelfile{net/ipv4}{tcp\_rmem}
2365 in \texttt{/proc/sys/net/ipv4}, vedi sez.~\ref{sec:sock_sysctl}.} indica
2366 la memoria effettivamente impiegata. Si tenga presente inoltre che le
2367 modifiche alle dimensioni dei buffer di ricezione e trasmissione, per poter
2368 essere effettive, devono essere impostate prima della chiamata alle funzioni
2369 \func{listen} o \func{connect}.
2371 \item[\const{SO\_LINGER}] questa opzione controlla le modalità con cui viene
2372 chiuso un socket quando si utilizza un protocollo che supporta le
2373 connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
2374 modifica il comportamento delle funzioni \func{close} e \func{shutdown}.
2375 L'opzione richiede che l'argomento \param{optval} sia una struttura di tipo
2376 \struct{linger}, definita in \headfile{sys/socket.h} ed illustrata in
2377 fig.~\ref{fig:sock_linger_struct}. Maggiori dettagli sul suo funzionamento
2378 sono forniti in sez.~\ref{sec:sock_options_main}.
2380 \item[\constd{SO\_PRIORITY}] questa opzione permette di impostare le priorità
2381 per tutti i pacchetti che sono inviati sul socket, prende per \param{optval}
2382 un valore intero. Con questa opzione il kernel usa il valore per ordinare le
2383 priorità sulle code di rete,\footnote{questo richiede che sia abilitato il
2384 sistema di \textit{Quality of Service} disponibile con le opzioni di
2385 routing avanzato.} i pacchetti con priorità più alta vengono processati
2386 per primi, in modalità che dipendono dalla disciplina di gestione della
2387 coda. Nel caso di protocollo IP questa opzione permette anche di impostare i
2388 valori del campo \textit{type of service} (noto come TOS, vedi
2389 sez.~\ref{sec:IP_header}) per i pacchetti uscenti. Per impostare una
2390 priorità al di fuori dell'intervallo di valori fra 0 e 6 sono richiesti i
2391 privilegi di amministratore con la capability \const{CAP\_NET\_ADMIN}.
2393 \item[\constd{SO\_ERROR}] questa opzione riceve un errore presente sul socket;
2394 può essere utilizzata soltanto con \func{getsockopt} e prende per
2395 \param{optval} un valore intero, nel quale viene restituito il codice di
2396 errore, e la condizione di errore sul socket viene cancellata. Viene
2397 usualmente utilizzata per ricevere il codice di errore, come accennato in
2398 sez.~\ref{sec:TCP_sock_select}, quando si sta osservando il socket con una
2399 \func{select} che ritorna a causa dello stesso.
2401 \item[\constd{SO\_ATTACH\_FILTER}] questa opzione permette di agganciare ad un
2402 socket un filtro di pacchetti che consente di selezionare quali pacchetti,
2403 fra tutti quelli ricevuti, verranno letti. Viene usato principalmente con i
2404 socket di tipo \const{PF\_PACKET} con la libreria \texttt{libpcap} per
2405 implementare programmi di cattura dei pacchetti, torneremo su questo in
2406 sez.~\ref{sec:packet_socket}.
2408 \item[\constd{SO\_DETACH\_FILTER}] consente di distaccare un filtro
2409 precedentemente aggiunto ad un socket.
2411 % TODO documentare SO_ATTACH_FILTER e SO_DETACH_FILTER
2412 % riferimenti http://www.rcpt.to/lsfcc/lsf.html
2413 % Documentation/networking/filter.txt
2415 % TODO documentare SO_MARK, introdotta nel 2.6.25, richiede CAP_NET_ADMIN
2416 %A userspace program may wish to set the mark for each packets its send
2417 %without using the netfilter MARK target. Changing the mark can be used
2418 %for mark based routing without netfilter or for packet filtering.
2421 % TODO documentare SO_TIMESTAMP e le altre opzioni di timestamping dei
2422 % pacchetti, introdotte nel 2.6.30, vedi nei sorgenti del kernel:
2423 % Documentation/networking/timestamping.txt
2426 % TOFO documentare SO_REUSEPORT introdotta con il kernel 3.9, vedi
2427 % http://git.kernel.org/linus/c617f398edd4db2b8567a28e899a88f8f574798d
2432 \subsection{L'uso delle principali opzioni dei socket}
2433 \label{sec:sock_options_main}
2435 La descrizione sintetica del significato delle opzioni generiche dei socket,
2436 riportata nell'elenco in sez.~\ref{sec:sock_generic_options}, è
2437 necessariamente sintetica, alcune di queste però possono essere utilizzate
2438 per controllare delle funzionalità che hanno una notevole rilevanza nella
2439 programmazione dei socket. Per questo motivo faremo in questa sezione un
2440 approfondimento sul significato delle opzioni generiche più importanti.
2443 \constbeg{SO\_KEEPALIVE}
2444 \subsubsection{L'opzione \const{SO\_KEEPALIVE}}
2446 La prima opzione da approfondire è \const{SO\_KEEPALIVE} che permette di
2447 tenere sotto controllo lo stato di una connessione. Una connessione infatti
2448 resta attiva anche quando non viene effettuato alcun traffico su di essa; è
2449 allora possibile, in caso di una interruzione completa della rete, che la
2450 caduta della connessione non venga rilevata, dato che sulla stessa non passa
2451 comunque alcun traffico.
2453 Se si imposta questa opzione, è invece cura del kernel inviare degli appositi
2454 messaggi sulla rete, detti appunto \textit{keep-alive}, per verificare se la
2455 connessione è attiva. L'opzione funziona soltanto con i socket che supportano
2456 le connessioni (non ha senso per socket UDP ad esempio) e si applica
2457 principalmente ai socket TCP.
2459 Con le impostazioni di default (che sono riprese da BSD) Linux emette un
2460 messaggio di \textit{keep-alive}\footnote{in sostanza un segmento ACK vuoto,
2461 cui sarà risposto con un altro segmento ACK vuoto.} verso l'altro capo della
2462 connessione se questa è rimasta senza traffico per più di due ore. Se è tutto
2463 a posto il messaggio viene ricevuto e verrà emesso un segmento ACK di
2464 risposta, alla cui ricezione ripartirà un altro ciclo di attesa per altre due
2465 ore di inattività; il tutto avviene all'interno del kernel e le applicazioni
2466 non riceveranno nessun dato.
2468 Qualora ci siano dei problemi di rete si possono invece verificare i due casi
2469 di terminazione precoce del server già illustrati in
2470 sez.~\ref{sec:TCP_conn_crash}. Il primo è quello in cui la macchina remota ha
2471 avuto un crollo del sistema ed è stata riavviata, per cui dopo il riavvio la
2472 connessione non esiste più.\footnote{si ricordi che un normale riavvio o il
2473 crollo dell'applicazione non ha questo effetto, in quanto in tal caso si
2474 passa sempre per la chiusura del processo, e questo, come illustrato in
2475 sez.~\ref{sec:file_open_close}, comporta anche la regolare chiusura del
2476 socket con l'invio di un segmento FIN all'altro capo della connessione.} In
2477 questo caso all'invio del messaggio di \textit{keep-alive} si otterrà come
2478 risposta un segmento RST che indica che l'altro capo non riconosce più
2479 l'esistenza della connessione ed il socket verrà chiuso riportando un errore
2480 di \errcode{ECONNRESET}.
2482 Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
2483 più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di 75
2484 secondi per un massimo di 9 volte\footnote{entrambi questi valori possono
2485 essere modificati a livello di sistema (cioè per tutti i socket) con gli
2486 opportuni parametri illustrati in sez.~\ref{sec:sock_sysctl} ed a livello di
2487 singolo socket con le opzioni \texttt{TCP\_KEEP*} di
2488 sez.~\ref{sec:sock_tcp_udp_options}.} (per un totale di 11 minuti e 15
2489 secondi) dopo di che, se non si è ricevuta nessuna risposta, il socket viene
2490 chiuso dopo aver impostato un errore di \errcode{ETIMEDOUT}. Qualora la
2491 connessione si sia ristabilita e si riceva un successivo messaggio di risposta
2492 il ciclo riparte come se niente fosse avvenuto. Infine se si riceve come
2493 risposta un pacchetto ICMP di destinazione irraggiungibile (vedi
2494 sez.~\ref{sec:ICMP_protocol}), verrà restituito l'errore corrispondente.
2496 In generale questa opzione serve per individuare una caduta della connessione
2497 anche quando non si sta facendo traffico su di essa. Viene usata
2498 principalmente sui server per evitare di mantenere impegnate le risorse che
2499 verrebbero dedicate a trattare delle connessioni che in realtà sono già
2500 terminate (quelle che vengono anche chiamate connessioni
2501 \textsl{semi-aperte}); in tutti quei casi cioè in cui il server si trova in
2502 attesa di dati in ingresso su una connessione che non arriveranno mai o perché
2503 il client sull'altro capo non è più attivo o perché non è più in grado di
2504 comunicare con il server via rete.
2506 \begin{figure}[!htbp]
2507 \footnotesize \centering
2508 \begin{minipage}[c]{\codesamplewidth}
2509 \includecodesample{listati/TCP_echod_fourth.c}
2512 \caption{La sezione della nuova versione del server del servizio
2513 \textit{echo} che prevede l'attivazione del \textit{keepalive} sui
2515 \label{fig:echod_keepalive_code}
2518 Abilitandola dopo un certo tempo le connessioni effettivamente terminate
2519 verranno comunque chiuse per cui, utilizzando ad esempio una \func{select}, se
2520 be potrà rilevare la conclusione e ricevere il relativo errore. Si tenga
2521 presente però che non può avere la certezza assoluta che un errore di
2522 \errcode{ETIMEDOUT} ottenuto dopo aver abilitato questa opzione corrisponda
2523 necessariamente ad una reale conclusione della connessione, il problema
2524 potrebbe anche essere dovuto ad un problema di routing che perduri per un
2525 tempo maggiore di quello impiegato nei vari tentativi di ritrasmissione del
2526 \textit{keep-alive} (anche se questa non è una condizione molto probabile).
2528 Come esempio dell'utilizzo di questa opzione introduciamo all'interno del
2529 nostro server per il servizio \textit{echo} la nuova opzione \texttt{-k} che
2530 permette di attivare il \textit{keep-alive} sui socket; tralasciando la parte
2531 relativa alla gestione di detta opzione (che si limita ad assegnare ad 1 la
2532 variabile \var{keepalive}) tutte le modifiche al server sono riportate in
2533 fig.~\ref{fig:echod_keepalive_code}. Al solito il codice completo è contenuto
2534 nel file \texttt{TCP\_echod\_fourth.c} dei sorgenti allegati alla guida.
2536 Come si può notare la variabile \var{keepalive} è preimpostata (\texttt{\small
2537 8}) ad un valore nullo; essa viene utilizzata sia come variabile logica per
2538 la condizione (\texttt{\small 14}) che controlla l'attivazione del
2539 \textit{keep-alive} che come valore dell'argomento \param{optval} della
2540 chiamata a \func{setsockopt} (\texttt{\small 16}). A seconda del suo valore
2541 tutte le volte che un processo figlio viene eseguito in risposta ad una
2542 connessione verrà pertanto eseguita o meno la sezione (\texttt{\small 14--17})
2543 che esegue l'impostazione di \const{SO\_KEEPALIVE} sul socket connesso,
2544 attivando il relativo comportamento.
2545 \constend{SO\_KEEPALIVE}
2549 \constbeg{SO\_REUSEADDR}
2550 \subsubsection{L'opzione \const{SO\_REUSEADDR}}
2552 La seconda opzione da approfondire è \const{SO\_REUSEADDR}, che consente di
2553 eseguire \func{bind} su un socket anche quando la porta specificata è già in
2554 uso da parte di un altro socket. Si ricordi infatti che, come accennato in
2555 sez.~\ref{sec:TCP_func_bind}, normalmente la funzione \func{bind} fallisce con
2556 un errore di \errcode{EADDRINUSE} se la porta scelta è già utilizzata da un
2557 altro socket, proprio per evitare che possano essere lanciati due server sullo
2558 stesso indirizzo e la stessa porta, che verrebbero a contendersi i pacchetti
2559 aventi quella destinazione.
2561 Esistono però situazioni ed esigenze particolari in cui non si vuole che
2562 questo comportamento di salvaguardia accada, ed allora si può fare ricorso a
2563 questa opzione. La questione è comunque abbastanza complessa in quanto, come
2564 sottolinea Stevens in \cite{UNP1}, si distinguono ben quattro casi diversi in
2565 cui è prevista la possibilità di un utilizzo di questa opzione, il che la
2566 rende una delle più difficili da capire.
2568 Il primo caso, che è anche il più comune, in cui si fa ricorso a
2569 \const{SO\_REUSEADDR} è quello in cui un server è terminato ma esistono ancora
2570 dei processi figli che mantengono attiva almeno una connessione remota che
2571 utilizza l'indirizzo locale, mantenendo occupata la porta. Quando si riesegue
2572 il server allora questo riceve un errore sulla chiamata a \func{bind} dato che
2573 la porta è ancora utilizzata in una connessione esistente.\footnote{questa è
2574 una delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
2575 quanto è piuttosto comune trovarsi in questa situazione quando si sta
2576 sviluppando un server che si ferma e si riavvia in continuazione dopo aver
2577 fatto modifiche.} Inoltre se si usa il protocollo TCP questo può avvenire
2578 anche dopo tutti i processi figli sono terminati, dato che una connessione può
2579 restare attiva anche dopo la chiusura del socket, mantenendosi nello stato
2580 \texttt{TIME\_WAIT} (vedi sez.~\ref{sec:TCP_time_wait}).
2582 Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
2583 \func{bind} si consente a quest'ultima di avere comunque successo anche se la
2584 connessione è attiva (o nello stato \texttt{TIME\_WAIT}). È bene però
2585 ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
2586 presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si usa
2587 questa opzione esiste sempre una probabilità, anche se estremamente
2588 remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
2589 indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
2590 numeri di sequenza dei pacchetti, e questo è estremamente improbabile.} che
2591 eventuali pacchetti rimasti intrappolati in una precedente connessione possano
2592 finire fra quelli di una nuova.
2594 Come esempio di uso di questa connessione abbiamo predisposto una nuova
2595 versione della funzione \texttt{sockbind} (vedi fig.~\ref{fig:sockbind_code})
2596 che consenta l'impostazione di questa opzione. La nuova funzione è
2597 \texttt{sockbindopt}, e le principali differenze rispetto alla precedente sono
2598 illustrate in fig.~\ref{fig:sockbindopt_code}, dove si sono riportate le
2599 sezioni di codice modificate rispetto alla versione precedente. Il codice
2600 completo della funzione si trova, insieme alle altre funzioni di servizio dei
2601 socket, all'interno del file \texttt{SockUtils.c} dei sorgenti allegati alla
2604 \begin{figure}[!htbp]
2605 \footnotesize \centering
2606 \begin{minipage}[c]{\codesamplewidth}
2607 \includecodesample{listati/sockbindopt.c}
2610 \caption{Le sezioni della funzione \texttt{sockbindopt} modificate rispetto al
2611 codice della precedente \texttt{sockbind}.}
2612 \label{fig:sockbindopt_code}
2615 In realtà tutto quello che si è fatto è stato introdurre nella nuova funzione
2616 (\texttt{\small 1}) un nuovo argomento intero, \param{reuse}, che conterrà il
2617 valore logico da usare nella successiva chiamata (\texttt{\small 14}) a
2618 \func{setsockopt}. Si è poi aggiunta una sezione (\texttt{\small 13--17}) che
2619 esegue l'impostazione dell'opzione fra la chiamata a \func{socket} e quella a
2623 A questo punto basterà modificare il server per utilizzare la nuova
2624 funzione; in fig.~\ref{fig:TCP_echod_fifth} abbiamo riportato le sezioni
2625 modificate rispetto alla precedente versione di
2626 fig.~\ref{fig:TCP_echod_third}. Al solito il codice completo è coi sorgenti
2627 allegati alla guida, nel file \texttt{TCP\_echod\_fifth.c}.
2629 Anche in questo caso si è introdotta (\texttt{\small 8}) una nuova variabile
2630 \var{reuse} che consente di controllare l'uso dell'opzione e che poi sarà
2631 usata (\texttt{\small 14}) come ultimo argomento di \func{setsockopt}. Il
2632 valore di default di questa variabile è nullo, ma usando l'opzione \texttt{-r}
2633 nell'invocazione del server (al solito la gestione delle opzioni non è
2634 riportata in fig.~\ref{fig:TCP_echod_fifth}) se ne potrà impostare ad 1 il
2635 valore, per cui in tal caso la successiva chiamata (\texttt{\small 13--17}) a
2636 \func{setsockopt} attiverà l'opzione \const{SO\_REUSEADDR}.
2638 \begin{figure}[!htbp]
2639 \footnotesize \centering
2640 \begin{minipage}[c]{\codesamplewidth}
2641 \includecodesample{listati/TCP_echod_fifth.c}
2644 \caption{Il nuovo codice per l'apertura passiva del server \textit{echo} che
2645 usa la nuova funzione \texttt{sockbindopt}.}
2646 \label{fig:TCP_echod_fifth}
2649 Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
2650 macchina cui sono assegnati diversi numeri IP (o come suol dirsi
2651 \textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
2652 programma diverso (o una istanza diversa dello stesso programma) per indirizzi
2653 IP diversi. Si ricordi infatti che è sempre possibile indicare a \func{bind}
2654 di collegarsi solo su di un indirizzo specifico; in tal caso se un altro
2655 programma cerca di riutilizzare la stessa porta (anche specificando un
2656 indirizzo diverso) otterrà un errore, a meno di non aver preventivamente
2657 impostato \const{SO\_REUSEADDR}.
2659 Usando questa opzione diventa anche possibile eseguire \func{bind}
2660 sull'indirizzo generico, e questo permetterà il collegamento per tutti gli
2661 indirizzi (di quelli presenti) per i quali la porta non risulti occupata da
2662 una precedente chiamata più specifica. Infine si tenga presente che con il
2663 protocollo TCP non è mai possibile far partire server che eseguano \func{bind}
2664 sullo stesso indirizzo e la stessa porta, cioè ottenere quello che viene
2665 chiamato un \textit{completely duplicate binding}.
2667 Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
2668 all'interno dello stesso programma per associare indirizzi locali diversi a
2669 socket diversi. In genere questo viene fatto per i socket UDP quando è
2670 necessario ottenere l'indirizzo a cui sono rivolte le richieste del client ed
2671 il sistema non supporta l'opzione \constd{IP\_RECVDSTADDR};\footnote{nel caso
2672 di Linux questa opzione è stata supportata per in certo periodo nello
2673 sviluppo del kernel 2.1.x, ma è in seguito stata soppiantata dall'uso di
2674 \const{IP\_PKTINFO} (vedi sez.~\ref{sec:sock_ipv4_options}).} in tale modo
2675 si può sapere a quale socket corrisponde un certo indirizzo. Non ha senso
2676 fare questa operazione per un socket TCP dato che su di essi si può sempre
2677 invocare \func{getsockname} una volta che si è completata la connessione.
2679 Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
2680 \textit{completely duplicate binding}, quando cioè si vuole eseguire
2681 \func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
2682 altro socket. Questo ovviamente non ha senso per il normale traffico di rete,
2683 in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma
2684 quando un sistema supporta il traffico in \textit{multicast}, allora ha senso
2685 che su una macchina i pacchetti provenienti dal traffico in \textit{multicast}
2686 possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
2687 traffico in \textit{multicast} è quello di uno streaming di dati (audio,
2688 video, ecc.), l'uso del \textit{multicast} consente in tal caso di
2689 trasmettere un solo pacchetto, che potrà essere ricevuto da tutti i
2690 possibili destinatari (invece di inviarne un duplicato a ciascuno); in
2691 questo caso è perfettamente logico aspettarsi che sulla stessa macchina più
2692 utenti possano lanciare un programma che permetta loro di ricevere gli
2693 stessi dati.} o da diverse istanze della stessa applicazione.
2695 In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una
2696 applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
2697 un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
2698 la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di
2699 applicazione è normale l'uso del protocollo UDP). La regola è che quando si
2700 hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
2701 tutti pacchetti destinati ad un indirizzo di \textit{broadcast} o di
2702 \textit{multicast} viene inviata una copia a ciascuna applicazione. Non è
2703 definito invece cosa accade qualora il pacchetto sia destinato ad un indirizzo
2706 Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
2707 introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta
2708 opzione sia specificata per tutti i socket per i quali si vuole eseguire il
2709 \textit{completely duplicate binding}. Nel caso di Linux questa opzione non
2710 esisteva fino al kernel 3.9, ma il comportamento di \const{SO\_REUSEADDR} è
2711 analogo, sarà cioè possibile effettuare un \textit{completely duplicate
2712 binding} ed ottenere il successo di \func{bind} su un socket legato allo
2713 stesso indirizzo e porta solo se il programma che ha eseguito per primo
2714 \func{bind} su di essi ha impostato questa opzione.\footnote{questa
2715 restrizione permette di evitare parzialmente il cosiddetto \textit{port
2716 stealing}, in cui un programma, usando \const{SO\_REUSEADDR}, può
2717 collegarsi ad una porta già in uso e ricevere i pacchetti destinati ad un
2718 altro programma; con questa caratteristica ciò è possibile soltanto se il
2719 primo programma a consentirlo, avendo usato fin dall'inizio
2720 \const{SO\_REUSEADDR}.}
2722 \constend{SO\_REUSEADDR}
2724 % TODO documentare SO_REUSEPORT, vedi https://lwn.net/Articles/542260/
2726 \constbeg{SO\_LINGER}
2727 \subsubsection{L'opzione \const{SO\_LINGER}}
2729 La terza opzione da approfondire è \const{SO\_LINGER}; essa, come il nome
2730 suggerisce, consente di ``\textsl{indugiare}'' nella chiusura di un socket. Il
2731 comportamento standard sia di \func{close} che \func{shutdown} è infatti
2732 quello di terminare immediatamente dopo la chiamata, mentre il procedimento di
2733 chiusura della connessione (o di un lato di essa) ed il rispettivo invio sulla
2734 rete di tutti i dati ancora presenti nei buffer, viene gestito in sottofondo
2737 \begin{figure}[!htb]
2738 \footnotesize \centering
2739 \begin{minipage}[c]{0.80\textwidth}
2740 \includestruct{listati/linger.h}
2742 \caption{La struttura \structd{linger} richiesta come valore dell'argomento
2743 \param{optval} per l'impostazione dell'opzione dei socket
2744 \const{SO\_LINGER}.}
2745 \label{fig:sock_linger_struct}
2748 L'uso di \const{SO\_LINGER} con \func{setsockopt} permette di modificare (ed
2749 eventualmente ripristinare) questo comportamento in base ai valori passati nei
2750 campi della struttura \struct{linger}, illustrata in
2751 fig.~\ref{fig:sock_linger_struct}. Fintanto che il valore del campo
2752 \var{l\_onoff} di \struct{linger} è nullo la modalità che viene impostata
2753 (qualunque sia il valore di \var{l\_linger}) è quella standard appena
2754 illustrata; questa combinazione viene utilizzata per riportarsi al
2755 comportamento normale qualora esso sia stato cambiato da una precedente
2758 Se si utilizza un valore di \var{l\_onoff} diverso da zero, il comportamento
2759 alla chiusura viene a dipendere dal valore specificato per il campo
2760 \var{l\_linger}; se quest'ultimo è nullo l'uso delle funzioni \func{close} e
2761 \func{shutdown} provoca la terminazione immediata della connessione: nel caso
2762 di TCP cioè non viene eseguito il procedimento di chiusura illustrato in
2763 sez.~\ref{sec:TCP_conn_term}, ma tutti i dati ancora presenti nel buffer
2764 vengono immediatamente scartati e sulla rete viene inviato un segmento di RST
2765 che termina immediatamente la connessione.
2767 Un esempio di questo comportamento si può abilitare nel nostro client del
2768 servizio \textit{echo} utilizzando l'opzione \texttt{-r}; riportiamo in
2769 fig.~\ref{fig:TCP_echo_sixth} la sezione di codice che permette di introdurre
2770 questa funzionalità; al solito il codice completo è disponibile nei sorgenti
2773 \begin{figure}[!htbp]
2774 \footnotesize \centering
2775 \begin{minipage}[c]{\codesamplewidth}
2776 \includecodesample{listati/TCP_echo_sixth.c}
2779 \caption{La sezione del codice del client \textit{echo} che imposta la
2780 terminazione immediata della connessione in caso di chiusura.}
2781 \label{fig:TCP_echo_sixth}
2784 La sezione indicata viene eseguita dopo aver effettuato la connessione e prima
2785 di chiamare la funzione di gestione, cioè fra le righe (\texttt{\small 12}) e
2786 (\texttt{\small 13}) del precedente esempio di fig.~\ref{fig:TCP_echo_fifth}.
2787 Il codice si limita semplicemente a controllare (\texttt{\small 3}) il
2788 valore della variabile \var{reset} che assegnata nella gestione delle opzioni
2789 in corrispondenza all'uso di \texttt{-r} nella chiamata del client. Nel caso
2790 questa sia diversa da zero vengono impostati (\texttt{\small 5--6}) i valori
2791 della struttura \var{ling} che permettono una terminazione immediata della
2792 connessione. Questa viene poi usata nella successiva (\texttt{\small 7})
2793 chiamata a \func{setsockopt}. Al solito si controlla (\texttt{\small 7--10})
2794 il valore di ritorno e si termina il programma in caso di errore, stampandone
2797 Infine l'ultima possibilità, quella in cui si utilizza effettivamente
2798 \const{SO\_LINGER} per \textsl{indugiare} nella chiusura, è quella in cui sia
2799 \var{l\_onoff} che \var{l\_linger} hanno un valore diverso da zero. Se si
2800 esegue l'impostazione con questi valori sia \func{close} che \func{shutdown}
2801 si bloccano, nel frattempo viene eseguita la normale procedura di conclusione
2802 della connessione (quella di sez.~\ref{sec:TCP_conn_term}) ma entrambe le
2803 funzioni non ritornano fintanto che non si sia concluso il procedimento di
2804 chiusura della connessione, o non sia passato un numero di
2805 secondi\footnote{questa è l'unità di misura indicata da POSIX ed adottata da
2806 Linux, altri kernel possono usare unità di misura diverse, oppure usare il
2807 campo \var{l\_linger} come valore logico (ignorandone il valore) per rendere
2808 (quando diverso da zero) \func{close} e \func{shutdown} bloccanti fino al
2809 completamento della trasmissione dei dati sul buffer.} pari al valore
2810 specificato in \var{l\_linger}.
2812 \constend{SO\_LINGER}
2816 \subsection{Le opzioni per il protocollo IPv4}
2817 \label{sec:sock_ipv4_options}
2819 Il secondo insieme di opzioni dei socket che tratteremo è quello relativo ai
2820 socket che usano il protocollo IPv4.\footnote{come per le precedenti opzioni
2821 generiche una descrizione di esse è disponibile nella settima sezione delle
2822 pagine di manuale, nel caso specifico la documentazione si può consultare
2823 con \texttt{man 7 ip}.} Se si vuole operare su queste opzioni generiche il
2824 livello da utilizzare è \const{SOL\_IP} (o l'equivalente
2825 \constd{IPPROTO\_IP}); si è riportato un elenco di queste opzioni in
2826 tab.~\ref{tab:sock_opt_iplevel}. Le costanti indicanti le opzioni e tutte le
2827 altre costanti ad esse collegate sono definite in \headfiled{netinet/ip.h}, ed
2828 accessibili includendo detto file.
2833 \begin{tabular}[c]{|l|c|c|c|l|p{6cm}|}
2835 \textbf{Opzione}&\texttt{get}&\texttt{set}&\textbf{flag}&\textbf{Tipo}&
2836 \textbf{Descrizione}\\
2839 \const{IP\_OPTIONS} &$\bullet$&$\bullet$&&\texttt{void *}& %???
2840 Imposta o riceve le opzioni di IP.\\
2841 \const{IP\_PKTINFO} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2842 Passa un messaggio di informazione.\\
2843 \const{IP\_RECVTOS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2844 Passa un messaggio col campo TOS.\\
2845 \const{IP\_RECVTTL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2846 Passa un messaggio col campo TTL.\\
2847 \const{IP\_RECVOPTS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2848 Passa un messaggio con le opzioni IP.\\
2849 \const{IP\_RETOPTS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2850 Passa un messaggio con le opzioni IP non trattate.\\
2851 \const{IP\_TOS} &$\bullet$&$\bullet$& &\texttt{int}&
2852 Imposta il valore del campo TOS.\\
2853 \const{IP\_TTL} &$\bullet$&$\bullet$& &\texttt{int}&
2854 Imposta il valore del campo TTL.\\
2855 \const{IP\_MINTTL} &$\bullet$&$\bullet$& &\texttt{int}&
2856 Imposta il valore minimo del TTL per i pacchetti accettati.\\
2857 \const{IP\_HDRINCL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2858 Passa l'intestazione di IP nei dati.\\
2859 \const{IP\_RECVERR} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2860 Abilita la gestione degli errori.\\
2861 \const{IP\_MTU\_DISCOVER} &$\bullet$&$\bullet$& &\texttt{int}&
2862 Imposta il \textit{Path MTU Discovery}.\\
2863 \const{IP\_MTU} &$\bullet$& & &\texttt{int}&
2864 Legge il valore attuale della MTU.\\
2865 \const{IP\_ROUTER\_ALERT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2866 Imposta l'opzione \textit{IP router alert} sui pacchetti.\\
2867 \const{IP\_MULTICAST\_TTL} &$\bullet$&$\bullet$& &\texttt{int}&
2868 Imposta il TTL per i pacchetti \textit{multicast}.\\
2869 \const{IP\_MULTICAST\_LOOP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
2870 Controlla il reinvio a se stessi dei dati di \textit{multicast}.\\
2871 \const{IP\_ADD\_MEMBERSHIP} & &$\bullet$& &\struct{ip\_mreqn}&
2872 Si unisce a un gruppo di \textit{multicast}.\\
2873 \const{IP\_DROP\_MEMBERSHIP}& &$\bullet$& &\struct{ip\_mreqn}&
2874 Si sgancia da un gruppo di \textit{multicast}.\\
2875 \const{IP\_MULTICAST\_IF} & &$\bullet$& &\struct{ip\_mreqn}&
2876 Imposta l'interfaccia locale di un socket \textit{multicast}.\\
2879 \caption{Le opzioni disponibili al livello \const{SOL\_IP}.}
2880 \label{tab:sock_opt_iplevel}
2883 Le descrizioni riportate in tab.~\ref{tab:sock_opt_iplevel} sono estremamente
2884 succinte, una maggiore quantità di dettagli sulle varie opzioni è fornita nel
2886 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
2889 \item[\constd{IP\_OPTIONS}] l'opzione permette di impostare o leggere le
2890 opzioni del protocollo IP (si veda sez.~\ref{sec:IP_options}). L'opzione
2891 prende come valore dell'argomento \param{optval} un puntatore ad un buffer
2892 dove sono mantenute le opzioni, mentre \param{optlen} indica la dimensione
2893 di quest'ultimo. Quando la si usa con \func{getsockopt} vengono lette le
2894 opzioni IP utilizzate per la spedizione, quando la si usa con
2895 \func{setsockopt} vengono impostate le opzioni specificate. L'uso di questa
2896 opzione richiede una profonda conoscenza del funzionamento del protocollo,
2897 torneremo in parte sull'argomento in sez.~\ref{sec:sock_IP_options}.
2900 \item[\constd{IP\_PKTINFO}] Quando abilitata l'opzione permette di ricevere
2901 insieme ai pacchetti un messaggio ancillare (vedi
2902 sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_PKTINFO} contenente
2903 una struttura \struct{pktinfo} (vedi fig.~\ref{fig:sock_pktinfo_struct}) che
2904 mantiene una serie di informazioni riguardo i pacchetti in arrivo. In
2905 particolare è possibile conoscere l'interfaccia su cui è stato ricevuto un
2906 pacchetto (nel campo \var{ipi\_ifindex}),\footnote{in questo campo viene
2907 restituito il valore numerico dell'indice dell'interfaccia,
2908 sez.~\ref{sec:sock_ioctl_netdevice}.} l'indirizzo locale da esso
2909 utilizzato (nel campo \var{ipi\_spec\_dst}) e l'indirizzo remoto dello
2910 stesso (nel campo \var{ipi\_addr}).
2912 \begin{figure}[!htb]
2913 \footnotesize \centering
2914 \begin{minipage}[c]{0.80\textwidth}
2915 \includestruct{listati/pktinfo.h}
2917 \caption{La struttura \structd{pktinfo} usata dall'opzione
2918 \const{IP\_PKTINFO} per ricavare informazioni sui pacchetti di un socket
2919 di tipo \const{SOCK\_DGRAM}.}
2920 \label{fig:sock_pktinfo_struct}
2924 L'opzione è utilizzabile solo per socket di tipo \const{SOCK\_DGRAM}. Questa è
2925 una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
2926 Linux;\footnote{non dovrebbe pertanto essere utilizzata se si ha a cuore la
2927 portabilità.} essa permette di sostituire le opzioni \const{IP\_RECVDSTADDR}
2928 e \const{IP\_RECVIF} presenti in altri Unix (la relativa informazione è quella
2929 ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
2932 L'opzione prende per \param{optval} un intero usato come valore logico, che
2933 specifica soltanto se insieme al pacchetto deve anche essere inviato o
2934 ricevuto il messaggio \const{IP\_PKTINFO} (vedi
2935 sez.~\ref{sec:net_ancillary_data}); il messaggio stesso dovrà poi essere
2936 letto o scritto direttamente con \func{recvmsg} e \func{sendmsg} (vedi
2937 sez.~\ref{sec:net_sendmsg}).
2940 \item[\constd{IP\_RECVTOS}] Quando abilitata l'opzione permette di ricevere
2941 insieme ai pacchetti un messaggio ancillare (vedi
2942 sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_TOS}, che contiene un
2943 byte con il valore del campo \textit{Type of Service} dell'intestazione IP
2944 del pacchetto stesso (vedi sez.~\ref{sec:IP_header}). Prende per
2945 \param{optval} un intero usato come valore logico.
2947 \item[\constd{IP\_RECVTTL}] Quando abilitata l'opzione permette di ricevere
2948 insieme ai pacchetti un messaggio ancillare (vedi
2949 sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_RECVTTL}, contenente
2950 un byte con il valore del campo \textit{Time to Live} dell'intestazione IP
2951 (vedi sez.~\ref{sec:IP_header}). L'opzione richiede per \param{optval} un
2952 intero usato come valore logico. L'opzione non è supportata per socket di
2953 tipo \const{SOCK\_STREAM}.
2955 \item[\constd{IP\_RECVOPTS}] Quando abilitata l'opzione permette di ricevere
2956 insieme ai pacchetti un messaggio ancillare (vedi
2957 sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_OPTIONS}, contenente
2958 le opzioni IP del protocollo (vedi sez.~\ref{sec:IP_options}). Le
2959 intestazioni di instradamento e le altre opzioni sono già riempite con i
2960 dati locali. L'opzione richiede per \param{optval} un intero usato come
2961 valore logico. L'opzione non è supportata per socket di tipo
2962 \const{SOCK\_STREAM}.
2964 \item[\constd{IP\_RETOPTS}] Identica alla precedente \const{IP\_RECVOPTS}, ma
2965 in questo caso restituisce i dati grezzi delle opzioni, senza che siano
2966 riempiti i capi di instradamento e le marche temporali. L'opzione richiede
2967 per \param{optval} un intero usato come valore logico. L'opzione non è
2968 supportata per socket di tipo \const{SOCK\_STREAM}.
2970 \item[\constd{IP\_TOS}] L'opzione consente di leggere o impostare il campo
2971 \textit{Type of Service} dell'intestazione IP (per una trattazione più
2972 dettagliata, che riporta anche i valori possibili e le relative costanti di
2973 definizione si veda sez.~\ref{sec:IP_header}) che permette di indicare le
2974 priorità dei pacchetti. Se impostato il valore verrà mantenuto per tutti i
2975 pacchetti del socket; alcuni valori (quelli che aumentano la priorità)
2976 richiedono i privilegi di amministrazione con la capability
2977 \const{CAP\_NET\_ADMIN}.
2979 Il campo TOS è di 8 bit e l'opzione richiede per \param{optval} un intero
2980 che ne contenga il valore. Sono definite anche alcune costanti che
2981 definiscono alcuni valori standardizzati per il \textit{Type of Service},
2982 riportate in tab.~\ref{tab:IP_TOS_values}, il valore di default usato da
2983 Linux è \const{IPTOS\_LOWDELAY}, ma esso può essere modificato con le
2984 funzionalità del cosiddetto \textit{Advanced Routing}. Si ricordi che la
2985 priorità dei pacchetti può essere impostata anche in maniera indipendente
2986 dal protocollo utilizzando l'opzione \const{SO\_PRIORITY} illustrata in
2987 sez.~\ref{sec:sock_generic_options}.
2989 \item[\constd{IP\_TTL}] L'opzione consente di leggere o impostare per tutti i
2990 pacchetti associati al socket il campo \textit{Time to Live}
2991 dell'intestazione IP che indica il numero massimo di \textit{hop} (passaggi
2992 da un router ad un altro) restanti al paccheto (per una trattazione più
2993 estesa si veda sez.~\ref{sec:IP_header}). Il campo TTL è di 8 bit e
2994 l'opzione richiede che \param{optval} sia un intero, che ne conterrà il
2997 \item[\constd{IP\_MINTTL}] L'opzione, introdotta con il kernel 2.6.34, imposta
2998 un valore minimo per il campo \textit{Time to Live} dei pacchetti associati
2999 al socket su cui è attivata, che se non rispettato ne causa lo scarto
3000 automatico. L'opzione è nata per implementare
3001 l'\href{http://www.ietf.org/rfc/rfc5082.txt}{RFC~5082} che la prevede come
3002 forma di protezione per i router che usano il protocollo BGP poiché questi,
3003 essendo in genere adiacenti, possono, impostando un valore di 255, scartare
3004 automaticamente tutti gli eventuali pacchetti falsi creati da un attacco a
3005 questo protocollo, senza doversi curare di verificarne la
3006 validità.\footnote{l'attacco viene in genere portato per causare un
3007 \textit{Denial of Service} aumentando il consumo di CPU del router nella
3008 verifica dell'autenticità di un gran numero di pacchetti di pacchetti
3009 falsi; questi, arrivando da sorgenti diverse da un router adiacente, non
3010 potrebbero più avere un TTL di 255 anche qualora questo fosse stato il
3011 valore di partenza, e l'impostazione dell'opzione consente di scartarli
3012 senza carico aggiuntivo sulla CPU (che altrimenti dovrebbe calcolare una
3015 \item[\constd{IP\_HDRINCL}] Se abilitata l'utente deve fornire lui stesso
3016 l'intestazione IP in cima ai propri dati. L'opzione è valida soltanto per
3017 socket di tipo \const{SOCK\_RAW}, e quando utilizzata eventuali valori
3018 impostati con \const{IP\_OPTIONS}, \const{IP\_TOS} o \const{IP\_TTL} sono
3019 ignorati. In ogni caso prima della spedizione alcuni campi
3020 dell'intestazione vengono comunque modificati dal kernel, torneremo
3021 sull'argomento in sez.~\ref{sec:socket_raw}
3023 \item[\constd{IP\_RECVERR}] Questa è una opzione introdotta con i kernel della
3024 serie 2.2.x, ed è specifica di Linux. Essa permette di usufruire di un
3025 meccanismo affidabile per ottenere un maggior numero di informazioni in caso
3026 di errori. Se l'opzione è abilitata tutti gli errori generati su un socket
3027 vengono memorizzati su una coda, dalla quale poi possono essere letti con
3028 \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) come messaggi ancillari
3029 (torneremo su questo in sez.~\ref{sec:net_ancillary_data}) di tipo
3030 \const{IP\_RECVERR}. L'opzione richiede per \param{optval} un intero usato
3031 come valore logico e non è applicabile a socket di tipo
3032 \const{SOCK\_STREAM}.
3035 \item[\constd{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
3036 della serie 2.2.x, ed è specifica di Linux. L'opzione permette di scrivere
3037 o leggere le impostazioni della modalità usata per la determinazione della
3038 \textit{Path MTU} (vedi sez.~\ref{sec:net_lim_dim}) del
3039 socket. L'opzione prende per \param{optval} un valore intero che indica la
3040 modalità usata, da specificare con una delle costanti riportate in
3041 tab.~\ref{tab:sock_ip_mtu_discover}.
3046 \begin{tabular}[c]{|l|r|p{7cm}|}
3048 \multicolumn{2}{|c|}{\textbf{Valore}}&\textbf{Significato} \\
3051 \constd{IP\_PMTUDISC\_DONT}&0& Non effettua la ricerca dalla \textit{Path
3053 \constd{IP\_PMTUDISC\_WANT}&1& Utilizza il valore impostato per la rotta
3054 utilizzata dai pacchetti (dal comando
3056 \constd{IP\_PMTUDISC\_DO} &2& Esegue la procedura di determinazione
3057 della \textit{Path MTU} come richiesto
3058 dall'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191}.\\
3061 \caption{Valori possibili per l'argomento \param{optval} di
3062 \const{IP\_MTU\_DISCOVER}.}
3063 \label{tab:sock_ip_mtu_discover}
3066 Il valore di default applicato ai socket di tipo \const{SOCK\_STREAM} è
3067 determinato dal parametro \texttt{ip\_no\_pmtu\_disc} (vedi
3068 sez.~\ref{sec:sock_sysctl}), mentre per tutti gli altri socket di default la
3069 ricerca è disabilitata ed è responsabilità del programma creare pacchetti di
3070 dimensioni appropriate e ritrasmettere eventuali pacchetti persi. Se
3071 l'opzione viene abilitata, il kernel si incaricherà di tenere traccia
3072 automaticamente della \textit{Path MTU} verso ciascuna destinazione, e
3073 rifiuterà immediatamente la trasmissione di pacchetti di dimensioni maggiori
3074 della MTU con un errore di \errval{EMSGSIZE}.\footnote{in caso contrario la
3075 trasmissione del pacchetto sarebbe effettuata, ottenendo o un fallimento
3076 successivo della trasmissione, o la frammentazione dello stesso.}
3078 \item[\constd{IP\_MTU}] Permette di leggere il valore della \textit{Path MTU}
3079 di percorso del socket. L'opzione richiede per \param{optval} un intero che
3080 conterrà il valore della \textit{Path MTU} in byte. Questa è una opzione
3081 introdotta con i kernel della serie 2.2.x, ed è specifica di Linux.
3083 È tramite questa opzione che un programma può leggere, quando si è avuto un
3084 errore di \errval{EMSGSIZE}, il valore della MTU corrente del socket. Si
3085 tenga presente che per poter usare questa opzione, oltre ad avere abilitato
3086 la scoperta della \textit{Path MTU}, occorre che il socket sia stato
3087 esplicitamente connesso con \func{connect}.
3089 Ad esempio con i socket UDP si potrà ottenere una stima iniziale della
3090 \textit{Path MTU} eseguendo prima una \func{connect} verso la destinazione,
3091 e poi usando \func{getsockopt} con questa opzione. Si può anche avviare
3092 esplicitamente il procedimento di scoperta inviando un pacchetto di grosse
3093 dimensioni (che verrà scartato) e ripetendo l'invio coi dati aggiornati. Si
3094 tenga infine conto che durante il procedimento i pacchetti iniziali possono
3095 essere perduti, ed è compito dell'applicazione gestirne una eventuale
3100 \item[\constd{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
3101 kernel della serie 2.2.x, ed è specifica di Linux. Prende per
3102 \param{optval} un intero usato come valore logico. Se abilitata
3103 passa tutti i pacchetti con l'opzione \textit{IP Router Alert} (vedi
3104 sez.~\ref{sec:IP_options}) che devono essere inoltrati al socket
3105 corrente. Può essere usata soltanto per socket di tipo raw.
3107 \item[\constd{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il
3108 valore del campo TTL per i pacchetti \textit{multicast} in uscita associati
3109 al socket. È importante che questo valore sia il più basso possibile, ed il
3110 default è 1, che significa che i pacchetti non potranno uscire dalla rete
3111 locale. Questa opzione consente ai programmi che lo richiedono di superare
3112 questo limite. L'opzione richiede per
3113 \param{optval} un intero che conterrà il valore del TTL.
3115 \item[\constd{IP\_MULTICAST\_LOOP}] L'opzione consente di decidere se i dati
3116 che si inviano su un socket usato con il \textit{multicast} vengano ricevuti
3117 anche sulla stessa macchina da cui li si stanno inviando. Prende per
3118 \param{optval} un intero usato come valore logico.
3120 In generale se si vuole che eventuali client possano ricevere i dati che si
3121 inviano occorre che questa funzionalità sia abilitata (come avviene di
3122 default). Qualora però non si voglia generare traffico per dati che già sono
3123 disponibili in locale l'uso di questa opzione permette di disabilitare
3124 questo tipo di traffico.
3126 \item[\constd{IP\_ADD\_MEMBERSHIP}] L'opzione consente di unirsi ad gruppo di
3127 \textit{multicast}, e può essere usata solo con \func{setsockopt}.
3128 L'argomento \param{optval} in questo caso deve essere una struttura di tipo
3129 \struct{ip\_mreqn}, illustrata in fig.~\ref{fig:ip_mreqn_struct}, che
3130 permette di indicare, con il campo \var{imr\_multiaddr} l'indirizzo del
3131 gruppo di \textit{multicast} a cui ci si vuole unire, con il campo
3132 \var{imr\_address} l'indirizzo dell'interfaccia locale con cui unirsi al
3133 gruppo di \textit{multicast} e con \var{imr\_ifindex} l'indice
3134 dell'interfaccia da utilizzare (un valore nullo indica una interfaccia
3137 Per compatibilità è possibile utilizzare anche un argomento di tipo
3138 \struct{ip\_mreq}, una precedente versione di \struct{ip\_mreqn}, che
3139 differisce da essa soltanto per l'assenza del campo \var{imr\_ifindex}.
3141 \begin{figure}[!htb]
3142 \footnotesize \centering
3143 \begin{minipage}[c]{0.80\textwidth}
3144 \includestruct{listati/ip_mreqn.h}
3146 \caption{La struttura \structd{ip\_mreqn} utilizzata dalle opzioni dei
3147 socket per le operazioni concernenti l'appartenenza ai gruppi di
3148 \textit{multicast}.}
3149 \label{fig:ip_mreqn_struct}
3152 \item[\constd{IP\_DROP\_MEMBERSHIP}] Lascia un gruppo di \textit{multicast},
3153 prende per \param{optval} la stessa struttura \struct{ip\_mreqn} (o
3154 \struct{ip\_mreq}) usata anche per \const{IP\_ADD\_MEMBERSHIP}.
3156 \item[\constd{IP\_MULTICAST\_IF}] Imposta l'interfaccia locale per l'utilizzo
3157 del \textit{multicast}, ed utilizza come \param{optval} le stesse strutture
3158 \struct{ip\_mreqn} o \struct{ip\_mreq} delle due precedenti opzioni.
3160 % TODO chiarire quale è la struttura \struct{ip\_mreq}
3167 \subsection{Le opzioni per i protocolli TCP e UDP}
3168 \label{sec:sock_tcp_udp_options}
3170 In questa sezione tratteremo le varie opzioni disponibili per i socket che
3171 usano i due principali protocolli di comunicazione del livello di trasporto;
3172 UDP e TCP.\footnote{come per le precedenti, una descrizione di queste opzioni
3173 è disponibile nella settima sezione delle pagine di manuale, che si può
3174 consultare rispettivamente con \texttt{man 7 tcp} e \texttt{man 7 udp}; le
3175 pagine di manuale però, alla stesura di questa sezione (Agosto 2006) sono
3176 alquanto incomplete.} Dato che questi due protocolli sono entrambi
3177 trasportati su IP,\footnote{qui si sottintende IPv4, ma le opzioni per TCP e
3178 UDP sono le stesse anche quando si usa IPv6.} oltre alle opzioni generiche
3179 di sez.~\ref{sec:sock_generic_options} saranno comunque disponibili anche le
3180 precedenti opzioni di sez.~\ref{sec:sock_ipv4_options}.\footnote{in realtà in
3181 sez.~\ref{sec:sock_ipv4_options} si sono riportate le opzioni per IPv4, al
3182 solito, qualora si stesse utilizzando IPv6, si potrebbero utilizzare le
3183 opzioni di quest'ultimo.}
3185 Il protocollo che supporta il maggior numero di opzioni è TCP; per poterle
3186 utilizzare occorre specificare \const{SOL\_TCP} (o l'equivalente
3187 \constd{IPPROTO\_TCP}) come valore per l'argomento \param{level}. Si sono
3188 riportate le varie opzioni disponibili in tab.~\ref{tab:sock_opt_tcplevel},
3189 dove sono elencate le rispettive costanti da utilizzare come valore per
3190 l'argomento \param{optname}. Dette costanti e tutte le altre costanti e
3191 strutture collegate all'uso delle opzioni TCP sono definite in
3192 \headfiled{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in
3193 realtà questo è il file usato dalle librerie; la definizione delle opzioni
3194 effettivamente supportate da Linux si trova nel file
3195 \texttt{include/linux/tcp.h} dei sorgenti del kernel, dal quale si sono
3196 estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
3201 \begin{tabular}[c]{|l|c|c|c|l|l|}
3203 \textbf{Opzione}&\texttt{get}&\texttt{set}&\textbf{flag}&\textbf{Tipo}&
3204 \textbf{Descrizione}\\
3207 \const{TCP\_NODELAY} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
3208 Spedisce immediatamente i dati in segmenti singoli.\\
3209 \const{TCP\_MAXSEG} &$\bullet$&$\bullet$& &\texttt{int}&
3210 Valore della MSS per i segmenti in uscita.\\
3211 \const{TCP\_CORK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
3212 Accumula i dati in un unico segmento.\\
3213 \const{TCP\_KEEPIDLE} &$\bullet$&$\bullet$& &\texttt{int}&
3214 Tempo in secondi prima di inviare un \textit{keepalive}.\\
3215 \const{TCP\_KEEPINTVL} &$\bullet$&$\bullet$& &\texttt{int}&
3216 Tempo in secondi prima fra \textit{keepalive} successivi.\\
3217 \const{TCP\_KEEPCNT} &$\bullet$&$\bullet$& &\texttt{int}&
3218 Numero massimo di \textit{keepalive} inviati.\\
3219 \const{TCP\_SYNCNT} &$\bullet$&$\bullet$& &\texttt{int}&
3220 Numero massimo di ritrasmissioni di un SYN.\\
3221 \const{TCP\_LINGER2} &$\bullet$&$\bullet$& &\texttt{int}&
3222 Tempo di vita in stato \texttt{FIN\_WAIT2}.\\
3223 \const{TCP\_DEFER\_ACCEPT}&$\bullet$&$\bullet$& &\texttt{int}&
3224 Ritorna da \func{accept} solo in presenza di dati.\\
3225 \const{TCP\_WINDOW\_CLAMP}&$\bullet$&$\bullet$& &\texttt{int}&
3226 Valore della \textit{advertised window}.\\
3227 \const{TCP\_INFO} &$\bullet$& & &\struct{tcp\_info}&
3228 Restituisce informazioni sul socket.\\
3229 \const{TCP\_QUICKACK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
3230 Abilita la modalità \textit{quickack}.\\
3231 \const{TCP\_CONGESTION} &$\bullet$&$\bullet$& &\texttt{char *}&
3232 Imposta l'algoritmo per il controllo della congestione.\\
3235 \caption{Le opzioni per i socket TCP disponibili al livello
3237 \label{tab:sock_opt_tcplevel}
3240 Le descrizioni delle varie opzioni riportate in
3241 tab.~\ref{tab:sock_opt_tcplevel} sono estremamente sintetiche ed indicative,
3242 la spiegazione del funzionamento delle singole opzioni con una maggiore
3243 quantità di dettagli è fornita nel seguente elenco:
3244 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
3246 \item[\constd{TCP\_NODELAY}] il protocollo TCP utilizza un meccanismo di
3247 bufferizzazione dei dati uscenti, per evitare la trasmissione di tanti
3248 piccoli segmenti con un utilizzo non ottimale della banda
3249 disponibile.\footnote{il problema è chiamato anche
3250 \itindex{silly~window~syndrome} \textit{silly window syndrome}, per averne
3251 un'idea si pensi al risultato che si ottiene quando un programma di
3252 terminale invia un segmento TCP per ogni tasto premuto, 40 byte di
3253 intestazione di protocollo con 1 byte di dati trasmessi; per evitare
3254 situazioni del genere è stato introdotto \index{algoritmo~di~Nagle}
3255 l'\textsl{algoritmo di Nagle}.} Questo meccanismo è controllato da un
3256 apposito algoritmo (detto \textsl{algoritmo di Nagle}, vedi
3257 sez.~\ref{sec:tcp_protocol_xxx}). Il comportamento normale del protocollo
3258 prevede che i dati siano accumulati fintanto che non si raggiunge una
3259 quantità considerata adeguata per eseguire la trasmissione di un singolo
3262 Ci sono però delle situazioni in cui questo comportamento può non essere
3263 desiderabile, ad esempio quando si sa in anticipo che l'applicazione invierà
3264 soltanto un piccolo quantitativo di dati;\footnote{è il caso classico di una
3265 richiesta HTTP.} in tal caso l'attesa introdotta dall'algoritmo di
3266 bufferizzazione non soltanto è inutile, ma peggiora le prestazioni
3267 introducendo un ritardo. Impostando questa opzione si disabilita l'uso
3268 dell'\textsl{algoritmo di Nagle} ed i dati vengono inviati immediatamente in
3269 singoli segmenti, qualunque sia la loro dimensione. Ovviamente l'uso di
3270 questa opzione è dedicato a chi ha esigenze particolari come quella
3271 illustrata, che possono essere stabilite solo per la singola applicazione.
3273 Si tenga conto che questa opzione viene sovrascritta dall'eventuale
3274 impostazione dell'opzione \const{TCP\_CORK} (il cui scopo è sostanzialmente
3275 l'opposto) che blocca l'invio immediato. Tuttavia quando la si abilita viene
3276 sempre forzato lo scaricamento della coda di invio (con conseguente
3277 trasmissione di tutti i dati pendenti), anche qualora si fosse già abilitata
3278 \const{TCP\_CORK}.\footnote{si tenga presente però che \const{TCP\_CORK} può
3279 essere specificata insieme a \const{TCP\_NODELAY} soltanto a partire dal
3282 \item[\constd{TCP\_MAXSEG}] con questa opzione si legge o si imposta il valore
3283 della MSS (\textit{Maximum Segment Size}, vedi sez.~\ref{sec:net_lim_dim} e
3284 sez.~\ref{sec:tcp_protocol_xxx}) dei segmenti TCP uscenti. Se l'opzione è
3285 impostata prima di stabilire la connessione, si cambia anche il valore della
3286 MSS annunciata all'altro capo della connessione. Se si specificano valori
3287 maggiori della MTU questi verranno ignorati, inoltre TCP imporrà anche i
3288 suoi limiti massimo e minimo per questo valore.
3290 \item[\constd{TCP\_CORK}] questa opzione è il complemento naturale di
3291 \const{TCP\_NODELAY} e serve a gestire a livello applicativo la situazione
3292 opposta, cioè quella in cui si sa fin dal principio che si dovranno inviare
3293 grosse quantità di dati. Anche in questo caso l'\textsl{algoritmo di Nagle}
3294 tenderà a suddividerli in dimensioni da lui ritenute
3295 opportune,\footnote{l'algoritmo cerca di tenere conto di queste situazioni,
3296 ma essendo un algoritmo generico tenderà comunque ad introdurre delle
3297 suddivisioni in segmenti diversi, anche quando potrebbero non essere
3298 necessarie, con conseguente spreco di banda.} ma sapendo fin dall'inizio
3299 quale è la dimensione dei dati si potranno di nuovo ottenere delle migliori
3300 prestazioni disabilitandolo, e gestendo direttamente l'invio del nostro
3301 blocco di dati in soluzione unica.
3303 Quando questa opzione viene abilitata non vengono inviati segmenti di dati
3304 fintanto che essa non venga disabilitata; a quel punto tutti i dati rimasti
3305 in coda saranno inviati in un solo segmento TCP. In sostanza con questa
3306 opzione si può controllare il flusso dei dati mettendo una sorta di
3307 ``\textsl{tappo}'' (da cui il nome in inglese) al flusso di uscita, in modo
3308 ottimizzare a mano l'uso della banda. Si tenga presente che per l'effettivo
3309 funzionamento ci si deve ricordare di disattivare l'opzione al termine
3310 dell'invio del blocco dei dati.
3312 Si usa molto spesso \const{TCP\_CORK} quando si effettua il trasferimento
3313 diretto di un blocco di dati da un file ad un socket con \func{sendfile}
3314 (vedi sez.~\ref{sec:file_sendfile_splice}), per inserire una intestazione
3315 prima della chiamata a questa funzione; senza di essa l'intestazione
3316 potrebbe venire spedita in un segmento a parte, che a seconda delle
3317 condizioni potrebbe richiedere anche una risposta di ACK, portando ad una
3318 notevole penalizzazione delle prestazioni.
3320 Si tenga presente che l'implementazione corrente di \const{TCP\_CORK} non
3321 consente di bloccare l'invio dei dati per più di 200 millisecondi, passati i
3322 quali i dati accumulati in coda sanno inviati comunque. Questa opzione è
3323 tipica di Linux\footnote{l'opzione è stata introdotta con i kernel della
3324 serie 2.4.x.} e non è disponibile su tutti i kernel unix-like, pertanto
3325 deve essere evitata se si vuole scrivere codice portabile.
3327 \item[\constd{TCP\_KEEPIDLE}] con questa opzione si legge o si imposta
3328 l'intervallo di tempo, in secondi, che deve trascorrere senza traffico sul
3329 socket prima che vengano inviati, qualora si sia attivata su di esso
3330 l'opzione \const{SO\_KEEPALIVE}, i messaggi di \textit{keep-alive} (si veda
3331 la trattazione relativa al \textit{keep-alive} in
3332 sez.~\ref{sec:sock_options_main}). Anche questa opzione non è disponibile
3333 su tutti i kernel unix-like e deve essere evitata se si vuole scrivere
3336 \item[\constd{TCP\_KEEPINTVL}] con questa opzione si legge o si imposta
3337 l'intervallo di tempo, in secondi, fra due messaggi di \textit{keep-alive}
3338 successivi (si veda sempre quanto illustrato in
3339 sez.~\ref{sec:sock_options_main}). Come la precedente non è disponibile su
3340 tutti i kernel unix-like e deve essere evitata se si vuole scrivere codice
3343 \item[\constd{TCP\_KEEPCNT}] con questa opzione si legge o si imposta il numero
3344 totale di messaggi di \textit{keep-alive} da inviare prima di concludere che
3345 la connessione è caduta per assenza di risposte ad un messaggio di
3346 \textit{keep-alive} (di nuovo vedi sez.~\ref{sec:sock_options_main}). Come
3347 la precedente non è disponibile su tutti i kernel unix-like e deve essere
3348 evitata se si vuole scrivere codice portabile.
3350 \item[\constd{TCP\_SYNCNT}] con questa opzione si legge o si imposta il numero
3351 di tentativi di ritrasmissione dei segmenti SYN usati nel \textit{three way
3352 handshake} prima che il tentativo di connessione venga abortito (si
3353 ricordi quanto accennato in sez.~\ref{sec:TCP_func_connect}). Sovrascrive
3354 per il singolo socket il valore globale impostato con la \textit{sysctl}
3355 \texttt{tcp\_syn\_retries} (vedi sez.~\ref{sec:sock_ipv4_sysctl}). Non
3356 vengono accettati valori maggiori di 255; anche questa opzione non è
3357 standard e deve essere evitata se si vuole scrivere codice portabile.
3359 \item[\constd{TCP\_LINGER2}] con questa opzione si legge o si imposta, in
3360 numero di secondi, il tempo di sussistenza dei socket terminati nello stato
3361 \texttt{FIN\_WAIT2} (si ricordi quanto visto in
3362 sez.~\ref{sec:TCP_conn_term}).\footnote{si tenga ben presente che questa
3363 opzione non ha nulla a che fare con l'opzione \const{SO\_LINGER} che
3364 abbiamo visto in sez.~\ref{sec:sock_options_main}.} Questa opzione
3365 consente di sovrascrivere per il singolo socket il valore globale impostato
3366 con la \textit{sysctl} \texttt{tcp\_fin\_timeout} (vedi
3367 sez.~\ref{sec:sock_ipv4_sysctl}). Anche questa opzione è da evitare se si
3368 ha a cuore la portabilità del codice.
3370 \item[\constd{TCP\_DEFER\_ACCEPT}] questa opzione consente di modificare il
3371 comportamento standard del protocollo TCP nello stabilirsi di una
3372 connessione; se ricordiamo il meccanismo del \textit{three way handshake}
3373 illustrato in fig.~\ref{fig:TCP_TWH} possiamo vedere che in genere un client
3374 inizierà ad inviare i dati ad un server solo dopo l'emissione dell'ultimo
3377 Di nuovo esistono situazioni (e la più tipica è quella di una richiesta
3378 HTTP) in cui sarebbe utile inviare immediatamente la richiesta all'interno
3379 del segmento con l'ultimo ACK del \textit{three way handshake}; si potrebbe
3380 così risparmiare l'invio di un segmento successivo per la richiesta e il
3381 ritardo sul server fra la ricezione dell'ACK e quello della richiesta.
3383 Se si invoca \const{TCP\_DEFER\_ACCEPT} su un socket dal lato client (cioè
3384 dal lato da cui si invoca \func{connect}) si istruisce il kernel a non
3385 inviare immediatamente l'ACK finale del \textit{three way handshake},
3386 attendendo per un po' di tempo la prima scrittura, in modo da inviare i dati
3387 di questa insieme col segmento ACK. Chiaramente la correttezza di questo
3388 comportamento dipende in maniera diretta dal tipo di applicazione che usa il
3389 socket; con HTTP, che invia una breve richiesta, permette di risparmiare un
3390 segmento, con FTP, in cui invece si attende la ricezione del prompt del
3391 server, introduce un inutile ritardo.
3393 Allo stesso tempo il protocollo TCP prevede che sul lato del server la
3394 funzione \func{accept} ritorni dopo la ricezione dell'ACK finale, in tal
3395 caso quello che si fa usualmente è lanciare un nuovo processo per leggere i
3396 successivi dati, che si bloccherà su una \func{read} se questi non sono
3397 disponibili; in questo modo si saranno impiegate delle risorse (per la
3398 creazione del nuovo processo) che non vengono usate immediatamente. L'uso
3399 di \const{TCP\_DEFER\_ACCEPT} consente di intervenire anche in questa
3400 situazione; quando la si invoca sul lato server (vale a dire su un socket in
3401 ascolto) l'opzione fa sì che \func{accept} ritorni soltanto quando sono
3402 presenti dei dati sul socket, e non alla ricezione dell'ACK conclusivo del
3403 \textit{three way handshake}.
3405 L'opzione prende un valore intero che indica il numero massimo di secondi
3406 per cui mantenere il ritardo, sia per quanto riguarda il ritorno di
3407 \func{accept} su un server, che per l'invio dell'ACK finale insieme ai dati
3408 su un client. L'opzione è specifica di Linux non deve essere utilizzata in
3409 codice che vuole essere portabile.\footnote{su FreeBSD è presente una
3410 opzione \texttt{SO\_ACCEPTFILTER} che consente di ottenere lo stesso
3411 comportamento di \const{TCP\_DEFER\_ACCEPT} per quanto riguarda il lato
3414 \item[\constd{TCP\_WINDOW\_CLAMP}] con questa opzione si legge o si imposta
3415 alla dimensione specificata, in byte, il valore dichiarato della
3416 \textit{advertised window} (vedi sez.~\ref{sec:tcp_protocol_xxx}). Il kernel
3417 impone comunque una dimensione minima pari a \texttt{SOCK\_MIN\_RCVBUF/2}.
3418 Questa opzione non deve essere utilizzata in codice che vuole essere
3421 \begin{figure}[!htb]
3422 \footnotesize \centering
3423 \begin{minipage}[c]{0.80\textwidth}
3424 \includestruct{listati/tcp_info.h}
3426 \caption{La struttura \structd{tcp\_info} contenente le informazioni sul
3427 socket restituita dall'opzione \const{TCP\_INFO}.}
3428 \label{fig:tcp_info_struct}
3431 \item[\constd{TCP\_INFO}] questa opzione, specifica di Linux, ma introdotta
3432 anche in altri kernel (ad esempio FreeBSD) permette di controllare lo stato
3433 interno di un socket TCP direttamente da un programma in user space.
3434 L'opzione restituisce in una speciale struttura \struct{tcp\_info}, la cui
3435 definizione è riportata in fig.~\ref{fig:tcp_info_struct}, tutta una serie
3436 di dati che il kernel mantiene, relativi al socket. Anche questa opzione
3437 deve essere evitata se si vuole scrivere codice portabile.
3439 Con questa opzione diventa possibile ricevere una serie di informazioni
3440 relative ad un socket TCP così da poter effettuare dei controlli senza dover
3441 passare attraverso delle operazioni di lettura. Ad esempio si può verificare
3442 se un socket è stato chiuso usando una funzione analoga a quella illustrata
3443 in fig.~\ref{fig:is_closing}, in cui si utilizza il valore del campo
3444 \var{tcpi\_state} di \struct{tcp\_info} per controllare lo stato del socket.
3446 \begin{figure}[!htbp]
3447 \footnotesize \centering
3448 \begin{minipage}[c]{\codesamplewidth}
3449 \includecodesample{listati/is_closing.c}
3451 \caption{Codice della funzione \texttt{is\_closing.c}, che controlla lo stato
3452 di un socket TCP per verificare se si sta chiudendo.}
3453 \label{fig:is_closing}
3456 %Si noti come nell'esempio si sia (
3459 \item[\constd{TCP\_QUICKACK}] con questa opzione è possibile eseguire una forma
3460 di controllo sull'invio dei segmenti ACK all'interno di in flusso di dati su
3461 TCP. In genere questo invio viene gestito direttamente dal kernel, il
3462 comportamento standard, corrispondente la valore logico di vero (in genere
3463 1) per questa opzione, è quello di inviare immediatamente i segmenti ACK, in
3464 quanto normalmente questo significa che si è ricevuto un blocco di dati e si
3465 può passare all'elaborazione del blocco successivo.
3467 Qualora però la nostra applicazione sappia in anticipo che alla ricezione di
3468 un blocco di dati seguirà immediatamente l'invio di un altro
3469 blocco,\footnote{caso tipico ad esempio delle risposte alle richieste HTTP.}
3470 poter accorpare quest'ultimo al segmento ACK permette di risparmiare sia in
3471 termini di dati inviati che di velocità di risposta. Per far questo si può
3472 utilizzare \const{TCP\_QUICKACK} impostando un valore logico falso (cioè 0),
3473 in questo modo il kernel attenderà così da inviare il prossimo segmento di
3474 ACK insieme ai primi dati disponibili.
3476 Si tenga presente che l'opzione non è permanente, vale a dire che una volta
3477 che la si sia impostata a 0 il kernel la riporterà al valore di default dopo
3478 il suo primo utilizzo. Sul lato server la si può impostare anche una volta
3479 sola su un socket in ascolto, ed essa verrà ereditata da tutti i socket che
3480 si otterranno da esso al ritorno di \func{accept}.
3482 % TODO trattare con gli esempi di apache
3484 \item[\constd{TCP\_CONGESTION}] questa opzione permette di impostare quale
3485 algoritmo per il controllo della congestione\footnote{il controllo della
3486 congestione è un meccanismo previsto dal protocollo TCP (vedi
3487 sez.~\ref{sec:tcp_protocol_xxx}) per evitare di trasmettere inutilmente
3488 dati quando una connessione è congestionata; un buon algoritmo è
3489 fondamentale per il funzionamento del protocollo, dato che i pacchetti
3490 persi andrebbero ritrasmessi, per cui inviare un pacchetto su una linea
3491 congestionata potrebbe causare facilmente un peggioramento della
3492 situazione.} utilizzare per il singolo socket. L'opzione è stata
3493 introdotta con il kernel 2.6.13,\footnote{alla data di stesura di queste
3494 note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
3495 definita nelle intestazioni delle \acr{glibc} per cui occorre definirla a
3496 mano al suo valore che è 13.} e prende come per \param{optval} il
3497 puntatore ad un buffer contenente il nome dell'algoritmo di controllo che
3500 L'uso di un nome anziché di un valore numerico è dovuto al fatto che gli
3501 algoritmi di controllo della congestione sono realizzati attraverso
3502 altrettanti moduli del kernel, e possono pertanto essere attivati a
3503 richiesta; il nome consente di caricare il rispettivo modulo e di introdurre
3504 moduli aggiuntivi che implementino altri meccanismi.
3506 Per poter disporre di questa funzionalità occorre aver compilato il kernel
3507 attivando l'opzione di configurazione generale
3508 \texttt{TCP\_CONG\_ADVANCED},\footnote{disponibile come \textit{TCP:
3509 advanced congestion control} nel menù \textit{Network->Networking
3510 options}, che a sua volta renderà disponibile un ulteriore menù con gli
3511 algoritmi presenti.} e poi abilitare i singoli moduli voluti con le varie
3512 \texttt{TCP\_CONG\_*} presenti per i vari algoritmi disponibili; un elenco
3513 di quelli attualmente supportati nella versione ufficiale del kernel è
3514 riportato in tab.~\ref{tab:sock_tcp_congestion_algo}.\footnote{la lista è
3515 presa dalla versione 2.6.17.}
3518 Si tenga presente che prima della implementazione modulare alcuni di questi
3519 algoritmi erano disponibili soltanto come caratteristiche generali del
3520 sistema, attivabili per tutti i socket, questo è ancora possibile con la
3521 \textit{sysctl} \texttt{tcp\_congestion\_control} (vedi
3522 sez.~\ref{sec:sock_ipv4_sysctl}) che ha sostituito le precedenti
3523 \textit{sysctl}.\footnote{riportate anche, alla data di stesura di queste
3524 pagine (Set. 2006) nelle pagine di manuale, ma non più presenti.}
3529 \begin{tabular}[c]{|l|l|l|}
3531 \textbf{Nome}&\textbf{Configurazione}&\textbf{Riferimento} \\
3534 reno& -- &Algoritmo tradizionale, usato in caso di assenza degli altri.\\
3535 \texttt{bic} &\texttt{TCP\_CONG\_BIC} &
3536 \url{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm}.\\
3537 \texttt{cubic} &\texttt{TCP\_CONG\_CUBIC} &
3538 \url{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm}.\\
3539 \texttt{highspeed}&\texttt{TCP\_CONG\_HSTCP} &
3540 \url{http://www.icir.org/floyd/hstcp.html}.\\
3541 \texttt{htcp} &\texttt{TCP\_CONG\_HTCP} &
3542 \url{http://www.hamilton.ie/net/htcp/}.\\
3543 \texttt{hybla} &\texttt{TCP\_CONG\_HYBLA} &
3544 \url{http://www.danielinux.net/projects.html}.\\
3545 \texttt{scalable}&\texttt{TCP\_CONG\_SCALABLE}&
3546 \url{http://www.deneholme.net/tom/scalable/}.\\
3547 \texttt{vegas} &\texttt{TCP\_CONG\_VEGAS} &
3548 \url{http://www.cs.arizona.edu/protocols/}.\\
3549 \texttt{westwood}&\texttt{TCP\_CONG\_WESTWOOD}&
3550 \url{http://www.cs.ucla.edu/NRL/hpi/tcpw/}.\\
3551 % \texttt{}&\texttt{}& .\\
3554 \caption{Gli algoritmi per il controllo della congestione disponibili con
3555 Linux con le relative opzioni di configurazione da attivare.}
3556 \label{tab:sock_tcp_congestion_algo}
3562 Il protocollo UDP, anche per la sua maggiore semplicità, supporta un numero
3563 ridotto di opzioni, riportate in tab.~\ref{tab:sock_opt_udplevel}; anche in
3564 questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
3565 l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
3566 \constd{IPPROTO\_UDP}). Le costanti che identificano dette opzioni sono
3567 definite in \headfiled{netinet/udp.h}, ed accessibili includendo detto
3568 file.\footnote{come per TCP, la definizione delle opzioni effettivamente
3569 supportate dal kernel si trova in realtà nel file
3570 \texttt{include/linux/udp.h}, dal quale si sono estratte le costanti di
3571 tab.~\ref{tab:sock_opt_udplevel}.}
3576 \begin{tabular}[c]{|l|c|c|c|l|l|}
3578 \textbf{Opzione}&\texttt{get}&\texttt{set}&\textbf{flag}&\textbf{Tipo}&
3579 \textbf{Descrizione}\\
3582 \constd{UDP\_CORK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& %???
3583 Accumula tutti i dati su un unico pacchetto.\\
3584 \constd{UDP\_ENCAP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& %???
3588 \caption{Le opzioni per i socket UDP disponibili al livello
3590 \label{tab:sock_opt_udplevel}
3593 % TODO documentare \const{UDP\_ENCAP}
3595 Ancora una volta le descrizioni contenute tab.~\ref{tab:sock_opt_udplevel}
3596 sono un semplice riferimento, una maggiore quantità di dettagli sulle
3597 caratteristiche delle opzioni citate è quello dell'elenco seguente:
3598 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
3600 \item[\constd{UDP\_CORK}] questa opzione ha l'identico effetto dell'analoga
3601 \const{TCP\_CORK} vista in precedenza per il protocollo TCP, e quando
3602 abilitata consente di accumulare i dati in uscita su un solo pacchetto che
3603 verrà inviato una volta che la si disabiliti. L'opzione è stata introdotta
3604 con il kernel 2.5.44, e non deve essere utilizzata in codice che vuole
3607 \item[\constd{UDP\_ENCAP}] Questa opzione permette di gestire l'incapsulazione
3608 dei dati nel protocollo UDP. L'opzione è stata introdotta con il kernel
3609 2.5.67, e non è documentata. Come la precedente è specifica di Linux e non
3610 deve essere utilizzata in codice portabile.
3617 \section{La gestione attraverso le funzioni di controllo}
3618 \label{sec:sock_ctrl_func}
3620 Benché la maggior parte delle caratteristiche dei socket sia gestibile con le
3621 funzioni \func{setsockopt} e \func{getsockopt}, alcune proprietà possono
3622 essere impostate attraverso le funzioni \func{fcntl} e \func{ioctl} già
3623 trattate in sez.~\ref{sec:file_fcntl_ioctl}; in quell'occasione abbiamo
3624 parlato di queste funzioni esclusivamente nell'ambito della loro applicazione
3625 a file descriptor associati a dei file normali; qui tratteremo invece i
3626 dettagli del loro utilizzo con file descriptor associati a dei socket.
3629 \subsection{L'uso di \func{ioctl} e \func{fcntl} per i socket generici}
3630 \label{sec:sock_ioctl}
3632 Tratteremo in questa sezione le caratteristiche specifiche delle funzioni
3633 \func{ioctl} e \func{fcntl} quando esse vengono utilizzate con dei socket
3634 generici. Quanto già detto in precedenza sez.~\ref{sec:file_fcntl_ioctl}
3635 continua a valere; quello che tratteremo qui sono le operazioni ed i comandi
3636 che sono validi, o che hanno significati peculiari, quando queste funzioni
3637 vengono applicate a dei socket generici.
3639 Nell'elenco seguente si riportano i valori specifici che può assumere il
3640 secondo argomento della funzione \func{ioctl} (\param{request}, che indica il
3641 tipo di operazione da effettuare) quando essa viene applicata ad un socket
3642 generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
3643 dato usato come terzo argomento della funzione ed il significato che esso
3644 viene ad assumere. Dato che in caso di lettura questi dati vengono restituiti
3645 come \textit{value result argument}, con queste operazioni il terzo argomento
3646 deve sempre essere passato come puntatore ad una variabile (o struttura)
3647 precedentemente allocata. Le costanti che identificano le operazioni sono le
3649 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
3650 \item[\constd{SIOCGSTAMP}] restituisce il contenuto di una struttura
3651 \struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
3652 socket, questa operazione può essere utilizzata per effettuare delle
3653 misurazioni precise del tempo di andata e ritorno\footnote{il \textit{Round
3654 Trip Time} cui abbiamo già accennato in sez.~\ref{sec:net_tcp}.} dei
3655 pacchetti sulla rete.
3657 \item[\constd{SIOCSPGRP}] imposta il processo o il \textit{process group} a cui
3658 inviare i segnali \signal{SIGIO} e \signal{SIGURG} quando viene completata
3659 una operazione di I/O asincrono o arrivano dei dati urgenti
3660 (\texttt{out-of-band}). Il terzo argomento deve essere un puntatore ad una
3661 variabile di tipo \type{pid\_t}; un valore positivo indica direttamente il
3662 \ids{PID} del processo, mentre un valore negativo indica (col valore
3663 assoluto) il \textit{process group}. Senza privilegi di amministratore o la
3664 capability \const{CAP\_KILL} si può impostare solo se stessi o il proprio
3665 \textit{process group}.
3667 \item[\constd{SIOCGPGRP}] legge le impostazioni presenti sul socket
3668 relativamente all'eventuale processo o \textit{process group} cui devono
3669 essere inviati i segnali \signal{SIGIO} e \signal{SIGURG}. Come per
3670 \const{SIOCSPGRP} l'argomento passato deve un puntatore ad una variabile di
3671 tipo \type{pid\_t}, con lo stesso significato. Qualora non sia presente
3672 nessuna impostazione verrà restituito un valore nullo.
3674 \item[\const{FIOASYNC}] Abilita o disabilita la modalità di I/O asincrono sul
3675 socket. Questo significa (vedi sez.~\ref{sec:signal_driven_io}) che verrà
3676 inviato il segnale di \signal{SIGIO} (o quanto impostato con
3677 \const{F\_SETSIG}, vedi sez.~\ref{sec:file_fcntl_ioctl}) in caso di eventi
3681 Nel caso dei socket generici anche \func{fcntl} prevede un paio di comandi
3682 specifici; in questo caso il secondo argomento (\param{cmd}, che indica il
3683 comando) può assumere i due valori \const{FIOGETOWN} e \const{FIOSETOWN},
3684 mentre il terzo argomento dovrà essere un puntatore ad una variabile di tipo
3685 \type{pid\_t}. Questi due comandi sono una modalità alternativa di eseguire le
3686 stesse operazioni (lettura o impostazione del processo o del gruppo di
3687 processo che riceve i segnali) che si effettuano chiamando \func{ioctl} con
3688 \const{SIOCGPGRP} e \const{SIOCSPGRP}.
3691 \subsection{L'uso di \func{ioctl} per l'accesso ai dispositivi di rete}
3692 \label{sec:sock_ioctl_netdevice}
3694 Benché non strettamente attinenti alla gestione dei socket, vale la pena di
3695 trattare qui l'interfaccia di accesso a basso livello ai dispositivi di rete
3696 che viene appunto fornita attraverso la funzione \texttt{ioctl}. Questa non è
3697 attinente a caratteristiche specifiche di un qualche protocollo, ma si applica
3698 a tutti i socket, indipendentemente da tipo e famiglia degli stessi, e
3699 permette di impostare e rilevare le funzionalità delle interfacce di rete.
3701 \begin{figure}[!htb]
3702 \footnotesize \centering
3703 \begin{minipage}[c]{0.80\textwidth}
3704 \includestruct{listati/ifreq.h}
3706 \caption{La struttura \structd{ifreq} utilizzata dalle \func{ioctl} per le
3707 operazioni di controllo sui dispositivi di rete.}
3708 \label{fig:netdevice_ifreq_struct}
3711 Tutte le operazioni di questo tipo utilizzano come terzo argomento di
3712 \func{ioctl} il puntatore ad una struttura \struct{ifreq}, la cui definizione
3713 è illustrata in fig.~\ref{fig:netdevice_ifreq_struct}. Normalmente si utilizza
3714 il primo campo della struttura, \var{ifr\_name} per specificare il nome
3715 dell'interfaccia su cui si vuole operare (ad esempio \texttt{eth0},
3716 \texttt{ppp0}, ecc.), e si inseriscono (o ricevono) i valori relativi alle
3717 diversa caratteristiche e funzionalità nel secondo campo, che come si può
3718 notare è definito come una \dirct{union} proprio in quanto il suo significato
3719 varia a secondo dell'operazione scelta.
3721 Si tenga inoltre presente che alcune di queste operazioni (in particolare
3722 quelle che modificano le caratteristiche dell'interfaccia) sono privilegiate e
3723 richiedono i privilegi di amministratore o la \textit{capability}
3724 \const{CAP\_NET\_ADMIN}, altrimenti si otterrà un errore di \errval{EPERM}.
3725 Le costanti che identificano le operazioni disponibili sono le seguenti:
3726 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
3727 \item[\constd{SIOCGIFNAME}] questa è l'unica operazione che usa il campo
3728 \var{ifr\_name} per restituire un risultato, tutte le altre lo utilizzano
3729 per indicare l'interfaccia sulla quale operare. L'operazione richiede che si
3730 indichi nel campo \var{ifr\_ifindex} il valore numerico dell'\textsl{indice}
3731 dell'interfaccia, e restituisce il relativo nome in \var{ifr\_name}.
3733 Il kernel infatti assegna ad ogni interfaccia un numero progressivo, detto
3734 appunto \itindex{interface~index} \textit{interface index}, che è quello che
3735 effettivamente la identifica nelle operazioni a basso livello, il nome
3736 dell'interfaccia è soltanto una etichetta associata a detto \textsl{indice},
3737 che permette di rendere più comprensibile l'indicazione dell'interfaccia
3738 all'interno dei comandi. Una modalità per ottenere questo valore è usare il
3739 comando \cmd{ip link}, che fornisce un elenco delle interfacce presenti
3740 ordinato in base a tale valore (riportato come primo campo).
3743 \item[\constd{SIOCGIFINDEX}] restituisce nel campo \var{ifr\_ifindex} il valore
3744 numerico dell'indice dell'interfaccia specificata con \var{ifr\_name}, è in
3745 sostanza l'operazione inversa di \const{SIOCGIFNAME}.
3747 \item[\constd{SIOCGIFFLAGS}] permette di ottenere nel campo \var{ifr\_flags} il
3748 valore corrente dei flag dell'interfaccia specificata (con \var{ifr\_name}).
3749 Il valore restituito è una maschera binaria i cui bit sono identificabili
3750 attraverso le varie costanti di tab.~\ref{tab:netdevice_iface_flag}.
3755 \begin{tabular}[c]{|l|p{8cm}|}
3757 \textbf{Flag} & \textbf{Significato} \\
3760 \constd{IFF\_UP} & L'interfaccia è attiva.\\
3761 \constd{IFF\_BROADCAST} & L'interfaccia ha impostato un indirizzo di
3762 \textit{broadcast} valido.\\
3763 \constd{IFF\_DEBUG} & È attivo il flag interno di debug.\\
3764 \constd{IFF\_LOOPBACK} & L'interfaccia è una interfaccia di
3765 \textit{loopback}.\\
3766 \constd{IFF\_POINTOPOINT}&L'interfaccia è associata ad un collegamento
3767 \textsl{punto-punto}.\\
3768 \constd{IFF\_RUNNING} & L'interfaccia ha delle risorse allocate (non può
3769 quindi essere disattivata).\\
3770 \constd{IFF\_NOARP} & L'interfaccia ha il protocollo ARP disabilitato o
3771 l'indirizzo del livello di rete non è impostato.\\
3772 \constd{IFF\_PROMISC} & L'interfaccia è nel cosiddetto
3773 \index{modo~promiscuo} \textsl{modo promiscuo},
3774 riceve cioè tutti i pacchetti che vede passare,
3775 compresi quelli non direttamente indirizzati a
3777 \constd{IFF\_NOTRAILERS}& Evita l'uso di \textit{trailer} nei pacchetti.\\
3778 \constd{IFF\_ALLMULTI} & Riceve tutti i pacchetti di \textit{multicast}.\\
3779 \constd{IFF\_MASTER} & L'interfaccia è il master di un bundle per il
3780 bilanciamento di carico.\\
3781 \constd{IFF\_SLAVE} & L'interfaccia è uno slave di un bundle per il
3782 bilanciamento di carico.\\
3783 \constd{IFF\_MULTICAST} & L'interfaccia ha il supporto per il
3784 \textit{multicast} attivo.\\
3785 \constd{IFF\_PORTSEL} & L'interfaccia può impostare i suoi parametri
3786 hardware (con l'uso di \struct{ifmap}).\\
3787 \constd{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare
3788 automaticamente il tipo di collegamento.\\
3789 \constd{IFF\_DYNAMIC} & Gli indirizzi assegnati all'interfaccia vengono
3790 persi quando questa viene disattivata.\\
3791 % \const{IFF\_} & .\\
3794 \caption{Le costanti che identificano i vari bit della maschera binaria
3795 \var{ifr\_flags} che esprime i flag di una interfaccia di rete.}
3796 \label{tab:netdevice_iface_flag}
3800 \item[\constd{SIOCSIFFLAGS}] permette di impostare il valore dei flag
3801 dell'interfaccia specificata (sempre con \var{ifr\_name}, non staremo a
3802 ripeterlo oltre) attraverso il valore della maschera binaria da passare nel
3803 campo \var{ifr\_flags}, che può essere ottenuta con l'OR aritmetico delle
3804 costanti di tab.~\ref{tab:netdevice_iface_flag}; questa operazione è
3807 \item[\constd{SIOCGIFMETRIC}] permette di leggere il valore della metrica del
3808 dispositivo associato all'interfaccia specificata nel campo
3809 \var{ifr\_metric}. Attualmente non è implementato, e l'operazione
3810 restituisce sempre un valore nullo.
3812 \item[\constd{SIOCSIFMETRIC}] permette di impostare il valore della metrica del
3813 dispositivo al valore specificato nel campo \var{ifr\_metric}, attualmente
3814 non ancora implementato, restituisce un errore di \errval{EOPNOTSUPP}.
3816 \item[\constd{SIOCGIFMTU}] permette di leggere il valore della \textit{Maximum
3817 Transfer Unit} del dispositivo nel campo \var{ifr\_mtu}.
3819 \item[\constd{SIOCSIFMTU}] permette di impostare il valore della
3820 \textit{Maximum Transfer Unit} del dispositivo al valore specificato campo
3821 \var{ifr\_mtu}. L'operazione è privilegiata, e si tenga presente che
3822 impostare un valore troppo basso può causare un blocco del kernel.
3824 \item[\constd{SIOCGIFHWADDR}] permette di leggere il valore dell'indirizzo
3825 hardware del dispositivo associato all'interfaccia nel campo
3826 \var{ifr\_hwaddr}; questo viene restituito come struttura \struct{sockaddr}
3827 in cui il campo \var{sa\_family} contiene un valore \texttt{ARPHRD\_*}
3828 indicante il tipo di indirizzo ed il campo \var{sa\_data} il valore binario
3829 dell'indirizzo hardware a partire dal byte 0.
3831 \item[\constd{SIOCSIFHWADDR}] permette di impostare il valore dell'indirizzo
3832 hardware del dispositivo associato all'interfaccia attraverso il valore
3833 della struttura \struct{sockaddr} (con lo stesso formato illustrato per
3834 \const{SIOCGIFHWADDR}) passata nel campo \var{ifr\_hwaddr}. L'operazione è
3837 \item[\constd{SIOCSIFHWBROADCAST}] imposta l'indirizzo \textit{broadcast}
3838 hardware dell'interfaccia al valore specificato dal campo
3839 \var{ifr\_hwaddr}. L'operazione è privilegiata.
3841 \item[\constd{SIOCGIFMAP}] legge alcuni parametri hardware (memoria, interrupt,
3842 canali di DMA) del driver dell'interfaccia specificata, restituendo i
3843 relativi valori nel campo \var{ifr\_map}; quest'ultimo contiene una
3844 struttura di tipo \struct{ifmap}, la cui definizione è illustrata in
3845 fig.~\ref{fig:netdevice_ifmap_struct}.
3847 \begin{figure}[!htb]
3848 \footnotesize \centering
3849 \begin{minipage}[c]{0.80\textwidth}
3850 \includestruct{listati/ifmap.h}
3852 \caption{La struttura \structd{ifmap} utilizzata per leggere ed impostare i
3853 valori dei parametri hardware di un driver di una interfaccia.}
3854 \label{fig:netdevice_ifmap_struct}
3857 \item[\constd{SIOCSIFMAP}] imposta i parametri hardware del driver
3858 dell'interfaccia specificata, restituendo i relativi valori nel campo
3859 \var{ifr\_map}. Come per \const{SIOCGIFMAP} questo deve essere passato come
3860 struttura \struct{ifmap}, secondo la definizione di
3861 fig.~\ref{fig:netdevice_ifmap_struct}.
3863 \item[\constd{SIOCADDMULTI}] aggiunge un indirizzo di \textit{multicast} ai
3864 filtri del livello di collegamento associati dell'interfaccia. Si deve usare
3865 un indirizzo hardware da specificare attraverso il campo \var{ifr\_hwaddr},
3866 che conterrà l'opportuna struttura \struct{sockaddr}; l'operazione è
3867 privilegiata. Per una modalità alternativa per eseguire la stessa operazione
3868 si possono usare i \textit{packet socket}, vedi
3869 sez.~\ref{sec:packet_socket}.
3871 \item[\constd{SIOCDELMULTI}] rimuove un indirizzo di \textit{multicast} ai
3872 filtri del livello di collegamento dell'interfaccia, vuole un indirizzo
3873 hardware specificato come per \const{SIOCADDMULTI}. Anche questa operazione
3874 è privilegiata e può essere eseguita in forma alternativa con i
3875 \textit{packet socket}.
3877 \item[\constd{SIOCGIFTXQLEN}] permette di leggere la lunghezza della coda di
3878 trasmissione del dispositivo associato all'interfaccia specificata nel campo
3881 \item[\constd{SIOCSIFTXQLEN}] permette di impostare il valore della lunghezza
3882 della coda di trasmissione del dispositivo associato all'interfaccia, questo
3883 deve essere specificato nel campo \var{ifr\_qlen}. L'operazione è
3886 \item[\constd{SIOCSIFNAME}] consente di cambiare il nome dell'interfaccia
3887 indicata da \var{ifr\_name} utilizzando il nuovo nome specificato nel campo
3893 % TODO aggiunta con il kernel 3.14 SIOCGHWTSTAMP per ottenere il timestamp
3894 % hardware senza modificarlo
3896 Una ulteriore operazione, che consente di ricavare le caratteristiche delle
3897 interfacce di rete, è \constd{SIOCGIFCONF}; però per ragioni di compatibilità
3898 questa operazione è disponibile soltanto per i socket della famiglia
3899 \const{AF\_INET} (vale ad dire per socket IPv4). In questo caso l'utente dovrà
3900 passare come argomento una struttura \struct{ifconf}, definita in
3901 fig.~\ref{fig:netdevice_ifconf_struct}.
3903 \begin{figure}[!htb]
3904 \footnotesize \centering
3905 \begin{minipage}[c]{0.80\textwidth}
3906 \includestruct{listati/ifconf.h}
3908 \caption{La struttura \structd{ifconf}.}
3909 \label{fig:netdevice_ifconf_struct}
3912 Per eseguire questa operazione occorrerà allocare preventivamente un buffer di
3913 contenente un vettore di strutture \struct{ifreq}. La dimensione (in byte) di
3914 questo buffer deve essere specificata nel campo \var{ifc\_len} di
3915 \struct{ifconf}, mentre il suo indirizzo andrà specificato nel campo
3916 \var{ifc\_req}. Qualora il buffer sia stato allocato come una stringa, il suo
3917 indirizzo potrà essere fornito usando il campo \var{ifc\_buf}.\footnote{si
3918 noti che l'indirizzo del buffer è definito in \struct{ifconf} con una
3919 \dirct{union}, questo consente di utilizzare una delle due forme a piacere.}
3921 La funzione restituisce nel buffer indicato una serie di strutture
3922 \struct{ifreq} contenenti nel campo \var{ifr\_name} il nome dell'interfaccia e
3923 nel campo \var{ifr\_addr} il relativo indirizzo IP. Se lo spazio allocato nel
3924 buffer è sufficiente il kernel scriverà una struttura \struct{ifreq} per
3925 ciascuna interfaccia attiva, restituendo nel campo \var{ifc\_len} il totale
3926 dei byte effettivamente scritti. Il valore di ritorno è 0 se l'operazione ha
3927 avuto successo e negativo in caso contrario.
3929 Si tenga presente che il kernel non scriverà mai sul buffer di uscita dati
3930 eccedenti numero di byte specificato col valore di \var{ifc\_len} impostato
3931 alla chiamata della funzione, troncando il risultato se questi non dovessero
3932 essere sufficienti. Questa condizione non viene segnalata come errore per cui
3933 occorre controllare il valore di \var{ifc\_len} all'uscita della funzione, e
3934 verificare che esso sia inferiore a quello di ingresso. In caso contrario si è
3935 probabilmente\footnote{probabilmente perché si potrebbe essere nella
3936 condizione in cui sono stati usati esattamente quel numero di byte.} avuta
3937 una situazione di troncamento dei dati.
3939 \begin{figure}[!htbp]
3940 \footnotesize \centering
3941 \begin{minipage}[c]{\codesamplewidth}
3942 \includecodesample{listati/iflist.c}
3944 \caption{Il corpo principale del programma \texttt{iflist.c}.}
3945 \label{fig:netdevice_iflist}
3948 Come esempio dell'uso di queste funzioni si è riportato in
3949 fig.~\ref{fig:netdevice_iflist} il corpo principale del programma
3950 \texttt{iflist} in cui si utilizza l'operazione \const{SIOCGIFCONF} per
3951 ottenere una lista delle interfacce attive e dei relativi indirizzi. Al solito
3952 il codice completo è fornito nei sorgenti allegati alla guida.
3954 Il programma inizia (\texttt{\small 7--11}) con la creazione del socket
3955 necessario ad eseguire l'operazione, dopo di che si inizializzano
3956 opportunamente (\texttt{\small 13--14}) i valori della struttura
3957 \struct{ifconf} indicando la dimensione del buffer ed il suo
3958 indirizzo;\footnote{si noti come in questo caso si sia specificato l'indirizzo
3959 usando il campo \var{ifc\_buf}, mentre nel seguito del programma si accederà
3960 ai valori contenuti nel buffer usando \var{ifc\_req}.} si esegue poi
3961 l'operazione invocando \func{ioctl}, controllando come sempre la corretta
3962 esecuzione, ed uscendo in caso di errore (\texttt{\small 15--19}).
3964 Si esegue poi un controllo sulla quantità di dati restituiti segnalando un
3965 eventuale overflow del buffer (\texttt{\small 21--23}); se invece è tutto a
3966 posto (\texttt{\small 24--27}) si calcola e si stampa a video il numero di
3967 interfacce attive trovate. L'ultima parte del programma (\texttt{\small
3968 28--33}) è il ciclo sul contenuto delle varie strutture \struct{ifreq}
3969 restituite in cui si estrae (\texttt{\small 30}) l'indirizzo ad esse
3970 assegnato\footnote{si è definito \var{access} come puntatore ad una struttura
3971 di tipo \struct{sockaddr\_in} per poter eseguire un \textit{casting}
3972 dell'indirizzo del valore restituito nei vari campi \var{ifr\_addr}, così
3973 poi da poterlo poi usare come argomento di \func{inet\_ntoa}.} e lo si
3974 stampa (\texttt{\small 31--32}) insieme al nome dell'interfaccia.
3978 \subsection{L'uso di \func{ioctl} per i socket TCP e UDP}
3979 \label{sec:sock_ioctl_IP}
3981 Non esistono operazioni specifiche per i socket IP in quanto tali,\footnote{a
3982 parte forse \const{SIOCGIFCONF}, che però resta attinente alle proprietà
3983 delle interfacce di rete, per cui l'abbiamo trattata in
3984 sez.~\ref{sec:sock_ioctl_netdevice} insieme alle altre che comunque si
3985 applicano anche ai socket IP.} mentre per i pacchetti di altri protocolli
3986 trasportati su IP, qualora li si gestisca attraverso dei socket, si dovrà fare
3987 riferimento direttamente all'eventuale supporto presente per il tipo di socket
3988 usato: ad esempio si possono ricevere pacchetti ICMP con socket di tipo
3989 \texttt{raw}, nel qual caso si dovrà fare riferimento alle operazioni di
3992 Tuttavia la gran parte dei socket utilizzati nella programmazione di rete
3993 utilizza proprio il protocollo IP, e quello che succede è che in realtà la
3994 funzione \func{ioctl} consente di effettuare alcune operazioni specifiche per
3995 i socket che usano questo protocollo, ma queste vendono eseguite, invece che a
3996 livello di IP, al successivo livello di trasporto, vale a dire in maniera
3997 specifica per i socket TCP e UDP.
3999 Le operazioni di controllo disponibili per i socket TCP sono illustrate dalla
4000 relativa pagina di manuale, accessibile con \texttt{man 7 tcp}, e prevedono
4001 come possibile valore per il secondo argomento della funzione le costanti
4002 illustrate nell'elenco seguente; il terzo argomento della funzione, gestito
4003 come \textit{value result argument}, deve essere sempre il puntatore ad una
4004 variabile di tipo \ctyp{int}:
4005 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
4006 \item[\constd{SIOCINQ}] restituisce la quantità di dati non ancora letti
4007 presenti nel buffer di ricezione; il socket non deve essere in stato
4008 \texttt{LISTEN}, altrimenti si avrà un errore di \errval{EINVAL}.
4009 \item[\constd{SIOCATMARK}] ritorna un intero non nullo, da intendere come
4010 valore logico, se il flusso di dati letti sul socket è arrivato sulla
4011 posizione (detta anche \textit{urgent mark}) in cui sono stati ricevuti dati
4012 urgenti (vedi sez.~\ref{sec:TCP_urgent_data}). Una operazione di lettura da
4013 un socket non attraversa mai questa posizione, per cui è possibile
4014 controllare se la si è raggiunta o meno con questa operazione.
4016 Questo è utile quando si attiva l'opzione \const{SO\_OOBINLINE} (vedi
4017 sez.~\ref{sec:sock_generic_options}) per ricevere i dati urgenti all'interno
4018 del flusso dei dati ordinari del socket;\footnote{vedremo in
4019 sez.~\ref{sec:TCP_urgent_data} che in genere i dati urgenti presenti su un
4020 socket si leggono \textit{out-of-band} usando un opportuno flag per
4021 \func{recvmsg}.} in tal caso quando \const{SIOCATMARK} restituisce un
4022 valore non nullo si saprà che la successiva lettura dal socket restituirà i
4023 dati urgenti e non il normale traffico; torneremo su questo in maggior
4024 dettaglio in sez.~\ref{sec:TCP_urgent_data}.
4026 \item[\constd{SIOCOUTQ}] restituisce la quantità di dati non ancora inviati
4027 presenti nel buffer di spedizione; come per \const{SIOCINQ} il socket non
4028 deve essere in stato \texttt{LISTEN}, altrimenti si avrà un errore di
4032 Le operazioni di controllo disponibili per i socket UDP, anch'esse illustrate
4033 dalla relativa pagina di manuale accessibile con \texttt{man 7 udp}, sono
4034 quelle indicate dalle costanti del seguente elenco; come per i socket TCP il
4035 terzo argomento viene gestito come \textit{value result argument} e deve
4036 essere un puntatore ad una variabile di tipo \ctyp{int}:
4037 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
4038 \item[\const{FIONREAD}] restituisce la dimensione in byte del primo pacchetto
4039 in attesa di ricezione, o 0 qualora non ci sia nessun pacchetto.
4040 \item[\const{TIOCOUTQ}] restituisce il numero di byte presenti nella coda di
4041 invio locale; questa opzione è supportata soltanto a partire dal kernel 2.4
4046 \section{La gestione con \func{sysctl} ed il filesystem \texttt{/proc}}
4047 \label{sec:sock_sysctl_proc}
4049 Come ultimo argomento di questo capitolo tratteremo l'uso della funzione
4050 \func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
4051 sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
4052 impostazioni relative alle proprietà dei socket. Dato che le stesse
4053 funzionalità sono controllabili direttamente attraverso il filesystem
4054 \texttt{/proc}, le tratteremo attraverso i file presenti in quest'ultimo.
4057 \subsection{L'uso di \func{sysctl} e \texttt{/proc} per le proprietà della
4059 \label{sec:sock_sysctl}
4061 La differenza nell'uso di \func{sysctl} e del filesystem \texttt{/proc}
4062 rispetto a quello delle funzioni \func{ioctl} e \func{fcntl} visto in
4063 sez.~\ref{sec:sock_ctrl_func} o all'uso di \func{getsockopt} e
4064 \func{setsockopt} è che queste funzioni consentono di controllare le proprietà
4065 di un singolo socket, mentre con \func{sysctl} e con \texttt{/proc} si
4066 impostano proprietà (o valori di default) validi a livello dell'intero
4067 sistema, e cioè per tutti i socket.
4069 Le opzioni disponibili per le proprietà della rete, nella gerarchia dei valori
4070 impostabili con \func{sysctl}, sono riportate sotto il nodo \texttt{net}, o,
4071 se acceduti tramite l'interfaccia del filesystem \texttt{/proc}, sotto
4072 \texttt{/proc/sys/net}. In genere sotto questa directory compaiono le
4073 sottodirectory (corrispondenti ad altrettanti sotto-nodi per \func{sysctl})
4074 relative ai vari protocolli e tipi di interfacce su cui è possibile
4075 intervenire per effettuare impostazioni; un contenuto tipico di questa
4076 directory è il seguente:
4087 e sono presenti varie centinaia di parametri, molti dei quali non sono neanche
4088 documentati; nel nostro caso ci limiteremo ad illustrare quelli più
4091 Si tenga presente infine che se è sempre possibile utilizzare il filesystem
4092 \texttt{/proc} come sostituto di \func{sysctl}, dato che i valori di nodi e
4093 sotto-nodi di quest'ultima sono mappati come file e directory sotto
4094 \texttt{/proc/sys/}, non è vero il contrario, ed in particolare Linux consente
4095 di impostare alcuni parametri o leggere lo stato della rete a livello di
4096 sistema sotto \texttt{/proc/net}, dove sono presenti dei file che non
4097 corrispondono a nessun nodo di \func{sysctl}.
4100 \subsection{I valori di controllo per i socket generici}
4101 \label{sec:sock_gen_sysctl}
4103 Nella directory \texttt{/proc/sys/net/core/} sono presenti i file
4104 corrispondenti ai parametri generici di \textit{sysctl} validi per tutti i
4105 socket. Quelli descritti anche nella pagina di manuale, accessibile con
4106 \texttt{man 7 socket} sono i seguenti:
4108 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
4109 \item[\sysctlrelfiled{net/core}{rmem\_default}] imposta la dimensione
4110 di default del buffer di ricezione (cioè per i dati in ingresso) dei socket.
4111 \item[\sysctlrelfiled{net/core}{rmem\_max}] imposta la dimensione
4112 massima che si può assegnare al buffer di ricezione dei socket attraverso
4113 l'uso dell'opzione \const{SO\_RCVBUF}.
4114 \item[\sysctlrelfiled{net/core}{wmem\_default}] imposta la dimensione
4115 di default del buffer di trasmissione (cioè per i dati in uscita) dei
4117 \item[\sysctlrelfiled{net/core}{wmem\_max}] imposta la dimensione
4118 massima che si può assegnare al buffer di trasmissione dei socket attraverso
4119 l'uso dell'opzione \const{SO\_SNDBUF}.
4120 \item[\sysctlrelfiled{net/core}{message\_cost},
4121 \sysctlrelfiled{net/core}{message\_burst}] contengono le impostazioni del
4122 \textit{bucket filter} che controlla l'emissione di
4123 messaggi di avviso da parte del kernel per eventi relativi a problemi sulla
4124 rete, imponendo un limite che consente di prevenire eventuali attacchi di
4125 \textit{Denial of Service} usando i log.\footnote{senza questo limite un
4126 attaccante potrebbe inviare ad arte un traffico che generi
4127 intenzionalmente messaggi di errore, per saturare il sistema dei log.}
4129 \itindbeg{bucket~filter}
4131 Il \textit{bucket filter} è un algoritmo generico che permette di impostare
4132 dei limiti di flusso su una quantità\footnote{uno analogo viene usato per
4133 imporre dei limiti sul flusso dei pacchetti nel \itindex{netfilter}
4134 \textit{netfilter} di Linux (il \textit{netfilter} è l'infrastruttura
4135 usata per il filtraggio dei pacchetti del kernel, per maggiori dettagli si
4136 consulti il cap.~2 di \cite{FwGL}).} senza dovere eseguire medie
4137 temporali, che verrebbero a dipendere in misura non controllabile dalla
4138 dimensione dell'intervallo su cui si media e dalla distribuzione degli
4139 eventi;\footnote{in caso di un picco di flusso (il cosiddetto
4140 \textit{burst}) il flusso medio verrebbe a dipendere in maniera esclusiva
4141 dalla dimensione dell'intervallo di tempo su cui calcola la media.} in
4142 questo caso si definisce la dimensione di un ``\textsl{bidone}'' (il
4143 \textit{bucket}) e del flusso che da esso può uscire, la presenza di una
4144 dimensione iniziale consente di assorbire eventuali picchi di emissione,
4145 l'aver fissato un flusso di uscita garantisce che a regime questo sarà il
4146 valore medio del flusso ottenibile dal \textit{bucket}.
4148 \itindend{bucket~filter}
4150 I due valori indicano rispettivamente il flusso a regime (non sarà inviato
4151 più di un messaggio per il numero di secondi specificato da
4152 \texttt{message\_cost}) e la dimensione iniziale per in caso di picco di
4153 emissione (verranno accettati inizialmente fino ad un massimo di
4154 \texttt{message\_cost/message\_burst} messaggi).
4156 \item[\sysctlrelfiled{net/core}{netdev\_max\_backlog}] numero massimo
4157 di pacchetti che possono essere contenuti nella coda di ingresso generale.
4159 \item[\sysctlrelfiled{net/core}{optmem\_max}] lunghezza massima dei
4160 dati ancillari e di controllo (vedi sez.~\ref{sec:net_ancillary_data}).
4163 Oltre a questi nella directory \texttt{/proc/sys/net/core} si trovano altri
4164 file, la cui documentazione dovrebbe essere mantenuta nei sorgenti del kernel,
4165 nel file \texttt{Documentation/networking/ip-sysctl.txt}; la maggior parte di
4166 questi però non è documentato:
4167 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
4168 \item[\sysctlrelfiled{net/core}{dev\_weight}] blocco di lavoro (\textit{work
4169 quantum}) dello \textit{scheduler} di processo dei pacchetti.
4171 % TODO da documentare meglio
4173 \item[\sysctlrelfiled{net/core}{lo\_cong}] valore per l'occupazione
4174 della coda di ricezione sotto la quale si considera di avere una bassa
4177 \item[\sysctlrelfiled{net/core}{mod\_cong}] valore per l'occupazione della
4178 coda di ricezione sotto la quale si considera di avere una congestione
4181 \item[\sysctlrelfiled{net/core}{no\_cong}] valore per l'occupazione della coda
4182 di ricezione sotto la quale si considera di non avere congestione.
4184 \item[\sysctlrelfiled{net/core}{no\_cong\_thresh}] valore minimo (\textit{low
4185 water mark}) per il riavvio dei dispositivi congestionati.
4187 % \item[\sysctlrelfiled{net/core}{netdev\_fastroute}] è presente
4188 % soltanto quando si è compilato il kernel con l'apposita opzione di
4189 % ottimizzazione per l'uso come router.
4191 \item[\sysctlrelfiled{net/core}{somaxconn}] imposta la dimensione massima
4192 utilizzabile per il \textit{backlog} della funzione \func{listen} (vedi
4193 sez.~\ref{sec:TCP_func_listen}), e corrisponde al valore della costante
4194 \constd{SOMAXCONN}; il suo valore di default è 128.
4199 \subsection{I valori di controllo per il protocollo IPv4}
4200 \label{sec:sock_ipv4_sysctl}
4202 Nella directory \texttt{/proc/sys/net/ipv4} sono presenti i file che
4203 corrispondono ai parametri dei socket che usano il protocollo IPv4, relativi
4204 quindi sia alle caratteristiche di IP, che a quelle degli altri protocolli che
4205 vengono usati all'interno di quest'ultimo (come ICMP, TCP e UDP) o a fianco
4206 dello stesso (come ARP).
4208 I file che consentono di controllare le caratteristiche specifiche del
4209 protocollo IP in quanto tale, che sono descritti anche nella relativa pagina
4210 di manuale accessibile con \texttt{man 7 ip}, sono i seguenti:
4211 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
4213 \item[\sysctlrelfiled{net/ipv4}{ip\_default\_ttl}] imposta il valore di
4214 default per il campo TTL (vedi sez.~\ref{sec:IP_header}) di tutti i
4215 pacchetti uscenti, stabilendo così il numero massimo di router che i
4216 pacchetti possono attraversare. Il valore può essere modificato anche per il
4217 singolo socket con l'opzione \const{IP\_TTL}. Prende un valore intero, ma
4218 dato che il campo citato è di 8 bit hanno senso solo valori fra 0 e 255. Il
4219 valore di default è 64, e normalmente non c'è nessuna necessità di
4220 modificarlo.\footnote{l'unico motivo sarebbe per raggiungere macchine
4221 estremamente ``{lontane}'' in termini di \textit{hop}, ma è praticamente
4222 impossibile trovarne.} Aumentare il valore è una pratica poco gentile, in
4223 quanto in caso di problemi di routing si allunga inutilmente il numero di
4226 \item[\sysctlrelfiled{net/ipv4}{ip\_forward}] abilita l'inoltro dei
4227 pacchetti da una interfaccia ad un altra, e può essere impostato anche per
4228 la singola interfaccia. Prende un valore logico (0 disabilita, diverso da
4229 zero abilita), di default è disabilitato.
4231 \item[\sysctlrelfiled{net/ipv4}{ip\_dynaddr}] abilita la riscrittura
4232 automatica degli indirizzi associati ad un socket quando una interfaccia
4233 cambia indirizzo. Viene usato per le interfacce usate nei collegamenti in
4234 dial-up, il cui indirizzo IP viene assegnato dinamicamente dal provider, e
4235 può essere modificato. Prende un valore intero, con 0 si disabilita la
4236 funzionalità, con 1 la si abilita, con 2 (o con qualunque altro valore
4237 diverso dai precedenti) la si abilità in modalità \textsl{prolissa}; di
4238 default la funzionalità è disabilitata.
4240 \item[\sysctlrelfiled{net/ipv4}{ip\_autoconfig}] specifica se
4241 l'indirizzo IP è stato configurato automaticamente dal kernel all'avvio
4242 attraverso DHCP, BOOTP o RARP. Riporta un valore logico (0 falso, 1 vero)
4243 accessibile solo in lettura, è inutilizzato nei kernel recenti ed eliminato
4244 a partire dal kernel 2.6.18.
4246 \item[\sysctlrelfiled{net/ipv4}{ip\_local\_port\_range}] imposta l'intervallo
4247 dei valori usati per l'assegnazione delle porte effimere, permette cioè di
4248 modificare i valori illustrati in fig.~\ref{fig:TCP_port_alloc}; prende due
4249 valori interi separati da spazi, che indicano gli estremi
4250 dell'intervallo. Si abbia cura di non definire un intervallo che si
4251 sovrappone a quello delle porte usate per il \textit{masquerading}, il
4252 kernel può gestire la sovrapposizione, ma si avrà una perdita di
4253 prestazioni. Si imposti sempre un valore iniziale maggiore di 1024 (o meglio
4254 ancora di 4096) per evitare conflitti con le porte usate dai servizi noti.
4256 \item[\sysctlrelfiled{net/ipv4}{ip\_no\_pmtu\_disc}] permette di disabilitare
4257 per i socket \const{SOCK\_STREAM} la ricerca automatica della \textit{Path
4258 MTU} (vedi sez.~\ref{sec:net_lim_dim} e
4259 sez.~\ref{sec:sock_ipv4_options}). Prende un valore logico, e di default è
4260 disabilitato (cioè la ricerca viene eseguita).
4262 In genere si abilita questo parametro quando per qualche motivo il
4263 procedimento del \textit{Path MTU discovery} fallisce; dato che questo può
4264 avvenire a causa di router\footnote{ad esempio se si scartano tutti i
4265 pacchetti ICMP, il problema è affrontato anche in sez.~3.4.4 di
4266 \cite{SGL}.} o interfacce\footnote{ad esempio se i due capi di un
4267 collegamento \textit{point-to-point} non si accordano sulla stessa MTU.}
4268 mal configurati è opportuno correggere le configurazioni, perché
4269 disabilitare globalmente il procedimento con questo parametro ha pesanti
4270 ripercussioni in termini di prestazioni di rete.
4272 \item[\sysctlrelfiled{net/ipv4}{ip\_always\_defrag}] fa si che tutti i
4273 pacchetti IP frammentati siano riassemblati, anche in caso in successivo
4274 immediato inoltro.\footnote{introdotto con il kernel 2.2.13, nelle versioni
4275 precedenti questo comportamento poteva essere solo stabilito un volta per
4276 tutte in fase di compilazione del kernel con l'opzione
4277 \texttt{CONFIG\_IP\_ALWAYS\_DEFRAG}.} Prende un valore logico e di default
4278 è disabilitato. Con i kernel dalla serie 2.4 in poi la deframmentazione
4279 viene attivata automaticamente quando si utilizza il sistema del
4280 \textit{netfilter}, e questo parametro non è più presente.
4282 \item[\sysctlrelfiled{net/ipv4}{ipfrag\_high\_thresh}] indica il limite
4283 massimo (espresso in numero di byte) sui pacchetti IP frammentati presenti
4284 in coda; quando questo valore viene raggiunta la coda viene ripulita fino al
4285 valore \texttt{ipfrag\_low\_thresh}. Prende un valore intero.
4287 \item[\sysctlrelfiled{net/ipv4}{ipfrag\_low\_thresh}] soglia bassa
4288 (specificata in byte) a cui viene riportata la coda dei pacchetti IP
4289 frammentati quando si raggiunge il valore massimo dato da
4290 \texttt{ipfrag\_high\_thresh}. Prende un valore intero.
4292 \item[\sysctlrelfiled{net/ipv4}{ip\_nonlocal\_bind}] se abilitato rende
4293 possibile ad una applicazione eseguire \func{bind} anche su un indirizzo che
4294 non è presente su nessuna interfaccia locale. Prende un valore logico e di
4295 default è disabilitato.
4297 Questo può risultare utile per applicazioni particolari (come gli
4298 \textit{sniffer}) che hanno la necessità di ricevere pacchetti anche non
4299 diretti agli indirizzi presenti sulla macchina, ad esempio per intercettare
4300 il traffico per uno specifico indirizzo che si vuole tenere sotto
4301 controllo. Il suo uso però può creare problemi ad alcune applicazioni.
4303 % \item[\texttt{neigh/*}] La directory contiene i valori
4304 % TODO trattare neigh/* nella parte su arp, da capire dove sarà.
4308 I file di \texttt{/proc/sys/net/ipv4} che invece fanno riferimento alle
4309 caratteristiche specifiche del protocollo TCP, elencati anche nella rispettiva
4310 pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
4311 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
4313 \item[\sysctlrelfiled{net/ipv4}{tcp\_abort\_on\_overflow}] indica al
4314 kernel di azzerare le connessioni quando il programma che le riceve è troppo
4315 lento ed incapace di accettarle. Prende un valore logico ed è disabilitato
4316 di default. Questo consente di recuperare le connessioni se si è avuto un
4317 eccesso dovuto ad un qualche picco di traffico, ma ovviamente va a discapito
4318 dei client che interrogano il server. Pertanto è da abilitare soltanto
4319 quando si è sicuri che non è possibile ottimizzare il server in modo che sia
4320 in grado di accettare connessioni più rapidamente.
4322 \item[\sysctlrelfiled{net/ipv4}{tcp\_adv\_win\_scale}] indica al kernel quale
4323 frazione del buffer associato ad un socket\footnote{quello impostato con
4324 \sysctlrelfile{net/ipv4}{tcp\_rmem}.} deve essere utilizzata per la
4325 finestra del protocollo TCP\footnote{in sostanza il valore che costituisce
4326 la \textit{advertised window} annunciata all'altro capo del socket.} e
4327 quale come buffer applicativo per isolare la rete dalle latenze
4328 dell'applicazione. Prende un valore intero che determina la suddetta
4329 frazione secondo la formula
4330 $\texttt{buffer}/2^\texttt{tcp\_adv\_win\_scale}$ se positivo o con
4331 $\texttt{buffer}-\texttt{buffer}/2^\texttt{tcp\_adv\_win\_scale}$ se
4332 negativo. Il default è 2 che significa che al buffer dell'applicazione
4333 viene riservato un quarto del totale.
4335 \item[\sysctlrelfiled{net/ipv4}{tcp\_app\_win}] indica la frazione della
4336 finestra TCP che viene riservata per gestire l'overhaed dovuto alla
4337 bufferizzazione. Prende un valore valore intero che consente di calcolare la
4338 dimensione in byte come il massimo fra la MSS e
4339 $\texttt{window}/2^\texttt{tcp\_app\_win}$. Un valore nullo significa che
4340 non viene riservato nessuno spazio; il valore di default è 31.
4342 % vecchi, presumibilmente usati quando gli algoritmi di congestione non erano
4344 % \item[\texttt{tcp\_bic}]
4345 % \item[\texttt{tcp\_bic\_low\_window}]
4346 % \item[\texttt{tcp\_bic\_fast\_convergence}]
4348 \item[\sysctlrelfiled{net/ipv4}{tcp\_dsack}] abilita il supporto,
4349 definito nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}, per il
4350 cosiddetto \textit{Duplicate SACK}.\footnote{si indica con SACK
4351 (\textit{Selective Acknowledgement}) un'opzione TCP, definita
4352 nell'\href{http://www.ietf.org/rfc/rfc2018.txt}{RFC~2018}, usata per dare
4353 un \textit{acknowledgement} unico su blocchi di pacchetti non contigui,
4354 che consente di diminuire il numero di pacchetti scambiati.} Prende un
4355 valore logico e di default è abilitato.
4356 % TODO documentare o descrivere che cos'è il Duplicate SACK o
4357 % mettere riferimento nelle appendici
4360 \item[\sysctlrelfiled{net/ipv4}{tcp\_ecn}] abilita il meccanismo della
4361 \textit{Explicit Congestion Notification} (in breve ECN) nelle connessioni
4362 TCP. Prende valore logico che di default è disabilitato. La \textit{Explicit
4363 Congestion Notification} \itindex{Explicit~Congestion~Notification} è un
4364 meccanismo che consente di notificare quando una rotta o una rete è
4365 congestionata da un eccesso di traffico,\footnote{il meccanismo è descritto
4366 in dettaglio nell'\href{http://www.ietf.org/rfc/rfc3168.txt}{RFC~3168}
4367 mentre gli effetti sulle prestazioni del suo utilizzo sono documentate
4368 nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}.} si può così
4369 essere avvisati e cercare rotte alternative oppure diminuire l'emissione di
4370 pacchetti (in modo da non aumentare la congestione).
4372 Si tenga presente che se si abilita questa opzione si possono avere dei
4373 malfunzionamenti apparentemente casuali dipendenti dalla destinazione,
4374 dovuti al fatto che alcuni vecchi router non supportano il meccanismo ed
4375 alla sua attivazione scartano i relativi pacchetti, bloccando completamente
4377 % TODO documentare o descrivere che cos'è l'Explicit Congestion Notification o
4378 % mettere riferimento nelle appendici
4381 \item[\sysctlrelfiled{net/ipv4}{tcp\_fack}] abilita il supporto per il
4382 \textit{TCP Forward Acknowledgement}, un algoritmo per il controllo della
4383 congestione del traffico. Prende un valore logico e di default è abilitato.
4385 % TODO documentare o descrivere che cos'è il TCP Forward Acknowledgement o
4386 % mettere riferimento nelle appendici
4388 \item[\sysctlrelfiled{net/ipv4}{tcp\_fin\_timeout}] specifica il numero di
4389 secondi da passare in stato \texttt{FIN\_WAIT2} nell'attesa delle ricezione
4390 del pacchetto FIN conclusivo, passati quali il socket viene comunque chiuso
4391 forzatamente. Prende un valore intero che indica i secondi e di default è
4392 60.\footnote{nei kernel della serie 2.2.x era il valore utilizzato era
4393 invece di 120 secondi.} L'uso di questa opzione realizza quella che in
4394 sostanza è una violazione delle specifiche del protocollo TCP, ma è utile
4395 per fronteggiare alcuni attacchi di \textit{Denial of Service}.
4397 \item[\sysctlrelfiled{net/ipv4}{tcp\_frto}] abilita il supporto per
4398 l'algoritmo F-RTO, un algoritmo usato per la ritrasmissione dei timeout del
4399 protocollo TCP, che diventa molto utile per le reti wireless dove la perdita
4400 di pacchetti è usualmente dovuta a delle interferenze radio, piuttosto che
4401 alla congestione dei router. Prende un valore logico e di default è
4404 \item[\sysctlrelfiled{net/ipv4}{tcp\_keepalive\_intvl}] indica il
4405 numero di secondi che deve trascorrere fra l'emissione di due successivi
4406 pacchetti di test quando è abilitata la funzionalità del \textit{keepalive}
4407 (vedi sez.~\ref{sec:sock_options_main}). Prende un valore intero che di
4410 \item[\sysctlrelfiled{net/ipv4}{tcp\_keepalive\_probes}] indica il
4411 massimo numero pacchetti di \textit{keepalive} (vedi
4412 sez.~\ref{sec:sock_options_main}) che devono essere inviati senza ricevere
4413 risposta prima che il kernel decida che la connessione è caduta e la
4414 termini. Prende un valore intero che di default è 9.
4416 \item[\sysctlrelfiled{net/ipv4}{tcp\_keepalive\_time}] indica il numero
4417 di secondi che devono passare senza traffico sulla connessione prima che il
4418 kernel inizi ad inviare pacchetti di pacchetti di
4419 \textit{keepalive}.\footnote{ha effetto solo per i socket per cui si è
4420 impostata l'opzione \const{SO\_KEEPALIVE} (vedi
4421 sez.~\ref{sec:sock_options_main}.} Prende un valore intero che di default
4422 è 7200, pari a due ore.
4424 \item[\sysctlrelfiled{net/ipv4}{tcp\_low\_latency}] indica allo stack
4425 TCP del kernel di ottimizzare il comportamento per ottenere tempi di latenza
4426 più bassi a scapito di valori più alti per l'utilizzo della banda. Prende un
4427 valore logico che di default è disabilitato in quanto un maggior utilizzo
4428 della banda è preferito, ma esistono applicazioni particolari in cui la
4429 riduzione della latenza è più importante (ad esempio per i cluster di
4430 calcolo parallelo) nelle quali lo si può abilitare.
4432 \item[\sysctlrelfiled{net/ipv4}{tcp\_max\_orphans}] indica il numero
4433 massimo di socket TCP ``\textsl{orfani}'' (vale a dire non associati a
4434 nessun file descriptor) consentito nel sistema.\footnote{trattasi in genere
4435 delle connessioni relative a socket chiusi che non hanno completato il
4436 processo di chiusura.} Quando il limite viene ecceduto la connessione
4437 orfana viene resettata e viene stampato un avvertimento. Questo limite viene
4438 usato per contrastare alcuni elementari attacchi di \textit{denial of
4439 service}. Diminuire il valore non è mai raccomandato, in certe condizioni
4440 di rete può essere opportuno aumentarlo, ma si deve tenere conto del fatto
4441 che ciascuna connessione orfana può consumare fino a 64K di memoria del
4442 kernel. Prende un valore intero, il valore di default viene impostato
4443 inizialmente al valore del parametro del kernel \texttt{NR\_FILE}, e viene
4444 aggiustato a seconda della memoria disponibile.
4446 % TODO verificare la spiegazione di connessione orfana.
4448 \item[\sysctlrelfiled{net/ipv4}{tcp\_max\_syn\_backlog}] indica la lunghezza
4449 della coda delle connessioni incomplete, cioè delle connessioni per le quali
4450 si è ricevuto un SYN di richiesta ma non l'ACK finale del \textit{three way
4451 handshake} (si riveda quanto illustrato in
4452 sez.~\ref{sec:TCP_func_listen}).
4454 Quando questo valore è superato il kernel scarterà immediatamente ogni
4455 ulteriore richiesta di connessione. Prende un valore intero; il default, che
4456 è 256, viene automaticamente portato a 1024 qualora nel sistema ci sia
4457 sufficiente memoria (se maggiore di 128Mb) e ridotto a 128 qualora la
4458 memoria sia poca (inferiore a 32Mb).\footnote{si raccomanda, qualora si
4459 voglia aumentare il valore oltre 1024, di seguire la procedura citata
4460 nella pagina di manuale di TCP, e modificare il valore della costante
4461 \texttt{TCP\_SYNQ\_HSIZE} nel file \texttt{include/net/tcp.h} dei sorgenti
4462 del kernel, in modo che sia $\mathtt{tcp\_max\_syn\_backlog} \ge
4463 \mathtt{16*TCP\_SYNQ\_HSIZE}$, per poi ricompilare il kernel.}
4465 \item[\sysctlrelfiled{net/ipv4}{tcp\_max\_tw\_buckets}] indica il
4466 numero massimo di socket in stato \texttt{TIME\_WAIT} consentito nel
4467 sistema. Prende un valore intero di default è impostato al doppio del valore
4468 del parametro \texttt{NR\_FILE}, ma che viene aggiustato automaticamente a
4469 seconda della memoria presente. Se il valore viene superato il socket viene
4470 chiuso con la stampa di un avviso; l'uso di questa funzionalità consente di
4471 prevenire alcuni semplici attacchi di \textit{denial of service}.
4474 \item[\sysctlrelfiled{net/ipv4}{tcp\_mem}] viene usato dallo stack TCP
4475 per gestire le modalità con cui esso utilizzerà la memoria. Prende una
4476 tripletta di valori interi, che indicano un numero di pagine:
4479 \item il primo valore, chiamato \textit{low} nelle pagine di manuale, indica
4480 il numero di pagine allocate sotto il quale non viene usato nessun
4481 meccanismo di regolazione dell'uso della memoria.
4483 \item il secondo valore, chiamato \textit{pressure} indica il numero di
4484 pagine allocate passato il quale lo stack TCP inizia a moderare il suo
4485 consumo di memoria; si esce da questo stato di \textsl{pressione} sulla
4486 memoria quando il numero di pagine scende sotto il precedente valore
4489 \item il terzo valore, chiamato \textit{high} indica il numero massimo di
4490 pagine che possono essere utilizzate dallo stack TCP/IP, e soprassiede
4491 ogni altro valore specificato dagli altri limiti del kernel.
4494 \item[\sysctlrelfiled{net/ipv4}{tcp\_orphan\_retries}] indica il numero
4495 massimo di volte che si esegue un tentativo di controllo sull'altro capo di
4496 una connessione che è stata già chiusa dalla nostra parte. Prende un valore
4497 intero che di default è 8.
4499 \item[\sysctlrelfiled{net/ipv4}{tcp\_reordering}] indica il numero
4500 massimo di volte che un pacchetto può essere riordinato nel flusso di dati,
4501 prima che lo stack TCP assuma che è andato perso e si ponga nello stato di
4502 \textit{slow start} (si veda sez.~\ref{sec:tcp_protocol_xxx}) viene usata
4503 questa metrica di riconoscimento dei riordinamenti per evitare inutili
4504 ritrasmissioni provocate dal riordinamento. Prende un valore intero che di
4505 default che è 3, e che non è opportuno modificare.
4507 \item[\sysctlrelfiled{net/ipv4}{tcp\_retrans\_collapse}] in caso di
4508 pacchetti persi durante una connessione, per ottimizzare l'uso della banda
4509 il kernel cerca di eseguire la ritrasmissione inviando pacchetti della
4510 massima dimensione possibile; in sostanza dati che in precedenza erano stati
4511 trasmessi su pacchetti diversi possono essere ritrasmessi riuniti su un solo
4512 pacchetto (o su un numero minore di pacchetti di dimensione
4513 maggiore). Prende un valore logico e di default è abilitato.
4515 \item[\sysctlrelfiled{net/ipv4}{tcp\_retries1}] imposta il massimo
4516 numero di volte che protocollo tenterà la ritrasmissione si un pacchetto su
4517 una connessione stabilita prima di fare ricorso ad ulteriori sforzi che
4518 coinvolgano anche il livello di rete. Passato questo numero di
4519 ritrasmissioni verrà fatto eseguire al livello di rete un tentativo di
4520 aggiornamento della rotta verso la destinazione prima di eseguire ogni
4521 successiva ritrasmissione. Prende un valore intero che di default è 3.
4523 \item[\sysctlrelfiled{net/ipv4}{tcp\_retries2}] imposta il numero di
4524 tentativi di ritrasmissione di un pacchetto inviato su una connessione già
4525 stabilita per il quale non si sia ricevuto una risposta di ACK (si veda
4526 anche quanto illustrato in sez.~\ref{sec:TCP_server_crash}). Prende un
4527 valore intero che di default è 15, il che comporta un tempo variabile fra 13
4528 e 30 minuti; questo non corrisponde a quanto richiesto
4529 nell'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} dove è indicato un
4530 massimo di 100 secondi, che però è un valore considerato troppo basso.
4532 \item[\sysctlrelfiled{net/ipv4}{tcp\_rfc1337}] indica al kernel di
4533 abilitare il comportamento richiesto
4534 nell'\href{http://www.ietf.org/rfc/rfc1337.txt}{RFC~1337}. Prende un valore
4535 logico e di default è disabilitato, il che significa che alla ricezione di
4536 un segmento RST in stato \texttt{TIME\_WAIT} il socket viene chiuso
4537 immediatamente senza attendere la conclusione del periodo di
4538 \texttt{TIME\_WAIT}.
4540 \item[\sysctlrelfiled{net/ipv4}{tcp\_rmem}] viene usato dallo stack TCP
4541 per controllare dinamicamente le dimensioni dei propri buffer di ricezione,
4542 anche in rapporto alla memoria disponibile. Prende una tripletta di valori
4543 interi separati da spazi che indicano delle dimensioni in byte:
4546 \item il primo valore, chiamato \textit{min} nelle pagine di manuale, indica
4547 la dimensione minima in byte del buffer di ricezione; il default è 4Kb, ma
4548 in sistemi con poca memoria viene automaticamente ridotto a
4549 \const{PAGE\_SIZE}. Questo valore viene usato per assicurare che anche in
4550 situazioni di pressione sulla memoria (vedi quanto detto per
4551 \sysctlrelfile{net/ipv4}{tcp\_rmem}) le allocazioni al di sotto di
4552 questo limite abbiamo comunque successo. Questo valore non viene comunque
4553 ad incidere sulla dimensione del buffer di ricezione di un singolo socket
4554 dichiarata con l'opzione \const{SO\_RCVBUF}.
4556 \item il secondo valore, denominato \textit{default} nelle pagine di
4557 manuale, indica la dimensione di default, in byte, del buffer di ricezione
4558 di un socket TCP. Questo valore sovrascrive il default iniziale impostato
4559 per tutti i socket con \sysctlfile{net/core/mem\_default} che vale per
4560 qualunque protocollo. Il default è 87380 byte, ridotto a 43689 per sistemi
4561 con poca memoria. Se si desiderano dimensioni più ampie per tutti i socket
4562 si può aumentare questo valore, ma se si vuole che in corrispondenza
4563 aumentino anche le dimensioni usate per la finestra TCP si deve abilitare
4564 il \textit{TCP window scaling} (di default è abilitato, vedi più avanti
4565 \sysctlrelfile{net/ipv4}{tcp\_window\_scaling}).
4567 \item il terzo valore, denominato \textit{max} nelle pagine di manuale,
4568 indica la dimensione massima in byte del buffer di ricezione di un socket
4569 TCP; il default è 174760 byte, che viene ridotto automaticamente a 87380
4570 per sistemi con poca memoria. Il valore non può comunque eccedere il
4571 limite generale per tutti i socket posto con
4572 \sysctlfile{net/core/rmem\_max}. Questo valore non viene ad
4573 incidere sulla dimensione del buffer di ricezione di un singolo socket
4574 dichiarata con l'opzione \const{SO\_RCVBUF}.
4577 \item[\sysctlrelfiled{net/ipv4}{tcp\_sack}] indica al kernel di
4578 utilizzare il meccanismo del \textit{TCP selective acknowledgement} definito
4579 nell'\href{http://www.ietf.org/rfc/rfc2018.txt}{RFC~2018}. Prende un valore
4580 logico e di default è abilitato.
4582 \item[\sysctlrelfiled{net/ipv4}{tcp\_stdurg}] indica al kernel di
4583 utilizzare l'interpretazione che viene data
4584 dall'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} del puntatore dei
4585 \textit{dati urgenti} (vedi sez.~\ref{sec:TCP_urgent_data}) in cui questo
4586 punta all'ultimo byte degli stessi; se disabilitato viene usata
4587 l'interpretazione usata da BSD per cui esso punta al primo byte successivo.
4588 Prende un valore logico e di default è disabilitato, perché abilitarlo può
4589 dar luogo a problemi di interoperabilità.
4591 \item[\sysctlrelfiled{net/ipv4}{tcp\_synack\_retries}] indica il numero
4592 massimo di volte che verrà ritrasmesso il segmento SYN/ACK nella creazione di
4593 una connessione (vedi sez.~\ref{sec:TCP_conn_cre}). Prende un valore intero
4594 ed il valore di default è 5; non si deve superare il valore massimo di 255.
4596 \item[\sysctlrelfiled{net/ipv4}{tcp\_syncookies}] abilita i \textit{TCP
4597 syncookies}.\footnote{per poter usare questa funzionalità è necessario
4598 avere abilitato l'opzione \texttt{CONFIG\_SYN\_COOKIES} nella compilazione
4599 del kernel.} Prende un valore logico, e di default è disabilitato. Questa
4600 funzionalità serve a fornire una protezione in caso di un attacco di tipo
4601 \textit{SYN flood}, e deve essere utilizzato come ultima risorsa dato che
4602 costituisce una violazione del protocollo TCP e confligge con altre
4603 funzionalità come le estensioni e può causare problemi per i client ed il
4604 reinoltro dei pacchetti.
4606 \item[\sysctlrelfiled{net/ipv4}{tcp\_syn\_retries}] imposta il numero di
4607 tentativi di ritrasmissione dei pacchetti SYN di inizio connessione del
4608 \textit{three way handshake} (si ricordi quanto illustrato in
4609 sez.~\ref{sec:TCP_func_connect}). Prende un valore intero che di default è
4610 5; non si deve superare il valore massimo di 255.
4612 \item[\sysctlrelfiled{net/ipv4}{tcp\_timestamps}] abilita l'uso dei
4613 \textit{TCP timestamps}, come definiti
4614 nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
4615 logico e di default è abilitato.
4617 \item[\sysctlrelfiled{net/ipv4}{tcp\_tw\_recycle}] abilita il riutilizzo
4618 rapido dei socket in stato \texttt{TIME\_WAIT}. Prende un valore logico e di
4619 default è disabilitato. Non è opportuno abilitare questa opzione che può
4620 causare problemi con il NAT.\footnote{il
4621 \itindex{Network~Address~Translation} \textit{Network Address Translation}
4622 è una tecnica, impiegata nei firewall e nei router, che consente di
4623 modificare al volo gli indirizzi dei pacchetti che transitano per una
4624 macchina, Linux la supporta con il \textit{netfilter}.}
4626 \item[\sysctlrelfiled{net/ipv4}{tcp\_tw\_reuse}] abilita il riutilizzo
4627 dello stato \texttt{TIME\_WAIT} quando questo è sicuro dal punto di vista
4628 del protocollo. Prende un valore logico e di default è disabilitato.
4630 \item[\sysctlrelfiled{net/ipv4}{tcp\_window\_scaling}] un valore
4631 logico, attivo di default, che abilita la funzionalità del
4632 \itindex{TCP~window~scaling} \textit{TCP window scaling} definita
4633 dall'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
4634 logico e di default è abilitato. Come accennato in
4635 sez.~\ref{sec:TCP_TCP_opt} i 16 bit della finestra TCP comportano un limite
4636 massimo di dimensione di 64Kb, ma esiste una opportuna opzione del
4637 protocollo che permette di applicare un fattore di scale che consente di
4638 aumentarne le dimensioni. Questa è pienamente supportata dallo stack TCP di
4639 Linux, ma se lo si disabilita la negoziazione del
4640 \itindex{TCP~window~scaling} \textit{TCP window scaling} con l'altro capo
4641 della connessione non viene effettuata.
4643 %\item[\sysctlrelfiled{net/ipv4}{tcp\_vegas\_cong\_avoid}]
4644 % TODO: controllare su internet
4646 %\item[\sysctlrelfiled{net/ipv4}{tcp\_westwood}]
4647 % TODO: controllare su internet
4649 \item[\sysctlrelfiled{net/ipv4}{tcp\_wmem}] viene usato dallo stack TCP
4650 per controllare dinamicamente le dimensioni dei propri buffer di spedizione,
4651 adeguandole in rapporto alla memoria disponibile. Prende una tripletta di
4652 valori interi separati da spazi che indicano delle dimensioni in byte:
4655 \item il primo valore, chiamato \textit{min}, indica la dimensione minima in
4656 byte del buffer di spedizione; il default è 4Kb. Come per l'analogo di
4657 \sysctlrelfile{net/ipv4}{tcp\_rmem}) viene usato per assicurare
4658 che anche in situazioni di pressione sulla memoria (vedi
4659 \sysctlrelfile{net/ipv4}{tcp\_mem}) le allocazioni al di sotto di
4660 questo limite abbiamo comunque successo. Di nuovo questo valore non viene
4661 ad incidere sulla dimensione del buffer di trasmissione di un singolo
4662 socket dichiarata con l'opzione \const{SO\_SNDBUF}.
4664 \item il secondo valore, denominato \textit{default}, indica la dimensione
4665 di default in byte del buffer di spedizione di un socket TCP. Questo
4666 valore sovrascrive il default iniziale impostato per tutti i tipi di
4667 socket con \sysctlfile{net/core/wmem\_default}. Il default è 87380 byte,
4668 ridotto a 43689 per sistemi con poca memoria. Si può aumentare questo
4669 valore quando si desiderano dimensioni più ampie del buffer di
4670 trasmissione per i socket TCP, ma come per il precedente
4671 \sysctlrelfile{net/ipv4}{tcp\_rmem}) se si vuole che in corrispondenza
4672 aumentino anche le dimensioni usate per la finestra TCP si deve abilitare
4673 il \textit{TCP window scaling} con
4674 \sysctlrelfile{net/ipv4}{tcp\_window\_scaling}.
4676 \item il terzo valore, denominato \textit{max}, indica la dimensione massima
4677 in byte del buffer di spedizione di un socket TCP; il default è 128Kb, che
4678 viene ridotto automaticamente a 64Kb per sistemi con poca memoria. Il
4679 valore non può comunque eccedere il limite generale per tutti i socket
4680 posto con \sysctlfile{net/core/wmem\_max}. Questo valore non viene
4681 ad incidere sulla dimensione del buffer di trasmissione di un singolo
4682 socket dichiarata con l'opzione \const{SO\_SNDBUF}.
4689 % LocalWords: socket sez dotted decimal resolver Domain Name Service cap DNS
4690 % LocalWords: client fig LDAP Lightweight Access Protocol NIS Information Sun
4691 % LocalWords: like netgroup Switch Solaris glibc libc uclib NSS tab shadow uid
4692 % LocalWords: username group aliases ethers MAC address hosts networks rpc RPC
4693 % LocalWords: protocols services dns db lib libnss org truelite it root res HS
4694 % LocalWords: resource init netinet resolv int void conf host LOCALDOMAIN TCP
4695 % LocalWords: options DEBUG debug AAONLY USEVC UDP PRIMARY IGNTC RECURSE INET
4696 % LocalWords: DEFNAMES search STAYOPEN DNSRCH INSECURE NOALIASES HOSTALIASES
4697 % LocalWords: IPv gethostbyname NOCHECKNAME KEEPTSIG TSIG BLAST RETRY retry NS
4698 % LocalWords: retrans query FQDN Fully Qualified const char dname class type
4699 % LocalWords: unsigned answer anslen CSNET Hesiod MIT CHAOS Chaosnet ANY BIND
4700 % LocalWords: nameser compat Berkley MF CNAME SOA MB MR NULL WKS PTR HINFO TXT
4701 % LocalWords: MINFO RP responsible person AFSDB AFS RT router NSAP SIG KEY PX
4702 % LocalWords: GPOS AAAA LOC NXT EID NIMLOC nimrod SRV ATMA ATM NAPTR naming AF
4703 % LocalWords: authority IXFR AXFR MAILB MAILA errno NOT FOUND RECOVERY TRY err
4704 % LocalWords: AGAIN herror netdb string perror error hstrerror strerror struct
4705 % LocalWords: hostent name addrtype length addr list sys af mygethost inet ret
4706 % LocalWords: ntop deep copy buf size buflen result errnop value argument len
4707 % LocalWords: ERANGE sethostent stayopen endhostent gethostbyaddr order pton
4708 % LocalWords: getipnodebyname getipnodebyaddr flags num MAPPED ALL ADDRCONFIG
4709 % LocalWords: freehostent ip getXXXbyname getXXXbyaddr servent getservbyname
4710 % LocalWords: netent getnetbyname getnetbyaddr protoent smtp udp
4711 % LocalWords: getprotobyname getprotobyaddr getservbyport port tcp setservent
4712 % LocalWords: getservent endservent setXXXent getXXXent endXXXent gethostent
4713 % LocalWords: setnetent getnetent endnetent setprotoent getprotoent POSIX RFC
4714 % LocalWords: endprotoent getaddrinfo getnameinfo nell' node service addrinfo
4715 % LocalWords: hints linked addrlen socklen family socktype protocol sockaddr
4716 % LocalWords: canonname next PF UNSPEC SOCK STREAM DGRAM bind INADDR loopback
4717 % LocalWords: connect sendto NUMERICHOST EAI NONAME SYSTEM BADFLAGS ADDRFAMILY
4718 % LocalWords: NODATA MEMORY FAIL errcode echo mygetaddr ptr casting Canonical
4719 % LocalWords: freeaddrinfo getservname salen hostlen serv servlen l'OR NI NUL
4720 % LocalWords: NOFQDN NAMEREQD NUMERICSERV MAXHOST MAXSERV sockconn SockUtil of
4721 % LocalWords: descriptor hint fifth sockbind setsockopt getsockopt sock level
4722 % LocalWords: optname optval optlen EBADF EFAULT EINVAL ENOPROTOOPT ENOTSOCK
4723 % LocalWords: IPPROTO Stevens ICMP ICMPV ICMPv get KEEPALIVE OOBINLINE timeval
4724 % LocalWords: RCVLOWAT SNDLOWAT RCVTIMEO SNDTIMEO BSDCOMPAT BSD PASSCRED ucred
4725 % LocalWords: PEERCRED BINDTODEVICE REUSEADDR ACCEPTCONN DONTROUTE gateway MSG
4726 % LocalWords: BROADCAST broadcast SNDBUF RCVBUF LINGER linger PRIORITY read IF
4727 % LocalWords: OOB recvmsg kernel select write readv recv recvfrom EAGAIN send
4728 % LocalWords: EWOULDBLOCK writev sendmsg raw domain SCM CREDENTIALS eth packet
4729 % LocalWords: IFNAMSIZ capabilities capability ADMIN log trpt EADDRINUSE close
4730 % LocalWords: listen routing sysctl shutdown Quality TOS keep alive ACK RST to
4731 % LocalWords: ECONNRESET ETIMEDOUT keepalive echod fourth newsgroup WAIT reuse
4732 % LocalWords: sockbindopt SockUtils homed completely binding RECVDSTADDR onoff
4733 % LocalWords: PKTINFO getsockname multicast streaming unicast REUSEPORT reset
4734 % LocalWords: stealing ling RECVTOS RECVTTL TTL RECVOPTS RETOPTS HDRINCL MTU
4735 % LocalWords: RECVERR DISCOVER Path Discovery ALERT alert ADD MEMBERSHIP mreqn
4736 % LocalWords: pktinfo ipi ifindex spec dst RECVIF Live IPTOS LOWDELAY Advanced
4737 % LocalWords: Transfer Unit PMTUDISC DONT WANT route dall' pmtu EMSGSIZE imr
4738 % LocalWords: multiaddr mreq fcntl ioctl request SIOCGSTAMP trip SIOCSPGRP pid
4739 % LocalWords: process SIGIO SIGURG KILL FIOASYNC SIOCGPGRP filesystem proc ttl
4740 % LocalWords: rmem wmem message cost burst bucket filter netdev backlog optmem
4741 % LocalWords: forward dynaddr dial autoconfig local masquerading ipfrag high
4742 % LocalWords: thresh low always defrag CONFIG SETSIG cmd FIOGETOWN FIOSETOWN
4743 % LocalWords: quest'ultime neigh dev weight cong mod somaxconn Di SIOCINQ DoS
4744 % LocalWords: Documentation SIOCATMARK SIOCOUTQ FIONREAD TIOCOUTQ Denial work
4745 % LocalWords: netfilter scheduler mark ARP DHCP BOOTP RARP nonlocal sniffer is
4746 % LocalWords: linux NODELAY MAXSEG CORK KEEPIDLE KEEPINTVL KEEPCNT SYNCNT INFO
4747 % LocalWords: DEFER ACCEPT WINDOW CLAMP QUICKACK CONGESTION ENCAP urgent MSS
4748 % LocalWords: Segment SYN accept advertised window info quickack Nagle ifreq
4749 % LocalWords: ifr ppp union EPERM SIOCGIFNAME dell' interface index IFF NOARP
4750 % LocalWords: SIOCGIFINDEX SIOCGIFFLAGS POINTOPOINT RUNNING PROMISC NOTRAILERS
4751 % LocalWords: ALLMULTI bundle PORTSEL ifmap AUTOMEDIA DYNAMIC SIOCSIFFLAGS way
4752 % LocalWords: SIOCGIFMETRIC SIOCSIFMETRIC SIOCGIFMTU SIOCSIFMTU SIOCGIFHWADDR
4753 % LocalWords: SIOCSIFHWADDR SIOCSIFHWBROADCAST SIOCGIFMAP SIOCSIFMAP sendfile
4754 % LocalWords: SIOCADDMULTI SIOCDELMULTI SIOCGIFTXQLEN SIOCSIFTXQLEN three syn
4755 % LocalWords: SIOCSIFNAME SIOCGIFCONF handshake retries MIN FreeBSD closing Mb
4756 % LocalWords: abort overflow adv win app bic convergence dsack ecn fack frto
4757 % LocalWords: intvl probes latency orphans l'ACK SYNQ HSIZE tw buckets mem rfc
4758 % LocalWords: orphan reordering collapse sack stdurg synack syncookies recycle
4759 % LocalWords: timestamps scaling vegas avoid westwood tcpi l'incapsulazione NR
4760 % LocalWords: metric EOPNOTSUPP mtu hwaddr ARPHRD interrupt DMA map qlen silly
4761 % LocalWords: rename ifconf syndrome dell'ACK FTP ACCEPTFILTER advanced reno
4762 % LocalWords: congestion control Networking cubic CUBIC highspeed HSTCP htcp
4763 % LocalWords: HTCP hybla HYBLA scalable SCALABLE ifc req iflist access ntoa Kb
4764 % LocalWords: hop Selective acknowledgement Explicit RTO stack firewall passwd
4765 % LocalWords: Notification wireless denial pressure ATTACH DETACH publickey
4766 % LocalWords: libpcap discovery point l'overhaed min PAGE flood NFS blast
4767 % LocalWords: selective COOKIES NAT Translation
4769 %%% Local Variables:
4771 %%% TeX-master: "gapil"