%% sockctrl.tex
%%
-%% Copyright (C) 2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2004-2005 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Prefazione",
internet invece che per numero IP attraverso il relativo \textsl{nome a
dominio}.\footnote{non staremo ad entrare nei dettagli della definizione di
cosa è un nome a dominio, dandolo per noto, una introduzione alla
- problematica si trova in \cite{AGL} (cap. 9) mentre per una trattazione
+ problematica si trova in \cite{AGL} (cap.~9) mentre per una trattazione
approfondita di tutte le problematiche relative al DNS si può fare
riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
server che forniscono su internet questo servizio, mentre nel nostro caso
\begin{figure}[htb]
\centering
- \includegraphics[width=10cm]{img/resolver}
+ \includegraphics[width=9cm]{img/resolver}
\caption{Schema di funzionamento delle routine del \textit{resolver}.}
\label{fig:sock_resolver_schema}
\end{figure}
funzioni di libreria, prevedendo un ordine di interrogazione predefinito e
non modificabile (a meno di una ricompilazione delle librerie stesse).}
+\index{\textit{Name~Service~Switch}|(}
Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
(\acr{uid}, ecc.).\\
\texttt{group} & corrispondenze fra nome del gruppo e proprietà dello
stesso.\\
- \texttt{aliases} & alias per la posta elettronica\\
+ \texttt{aliases} & alias per la posta elettronica.\\
\texttt{ethers} & corrispondenze fra numero IP e MAC address della
scheda di rete.\\
\texttt{hosts} & corrispondenze fra nome a dominio e numero IP.\\
disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
quelle che tratteremo nelle sezioni successive.
+\index{\textit{Name~Service~Switch}|)}
\subsection{Le funzioni di interrogazione del \textit{resolver}}
argument}) i propri risultati. La funzione infatti è rientrante, ed alloca
autonomamente tutta la memoria necessaria in cui verranno riportati i
risultati della risoluzione. La funzione scriverà in \param{res} il puntatore
-iniziale ad una \textit{linked list} di strutture di tipo \struct{addrinfo}
-contenenti tutte le informazioni ottenute.
+iniziale ad una \index{\textit{linked~list}}\textit{linked list} di strutture
+di tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
La funzione restituisce un valore nullo in caso di successo, o un codice in
caso di errore. I valori usati come codice di errore sono riportati in
\begin{figure}[!htb]
\centering
\includegraphics[width=10cm]{img/addrinfo_list}
- \caption{La \textit{linked list} delle strutture \struct{addrinfo}
- restituite da \func{getaddrinfo}.}
+ \caption{La \index{\textit{linked~list}}\textit{linked list} delle strutture
+ \struct{addrinfo} restituite da \func{getaddrinfo}.}
\label{fig:sock_addrinfo_list}
\end{figure}
\end{Verbatim}
%$
-Una volta estratti i risultati dalla \textit{linked list} puntata da
-\param{res} se questa non viene più utilizzata si dovrà avere cura di
-disallocare opportunamente tutta la memoria, per questo viene fornita
-l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
+Una volta estratti i risultati dalla
+\index{\textit{linked~list}}\textit{linked list} puntata da \param{res} se
+questa non viene più utilizzata si dovrà avere cura di disallocare
+opportunamente tutta la memoria, per questo viene fornita l'apposita funzione
+\funcd{freeaddrinfo}, il cui prototipo è:
\begin{functions}
\headdecl{netdb.h}
sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
dimensione in byte dei dati presenti all'indirizzo indicato da \param{optval}.
Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
-individuare qual'è quello che deve essere usato, ed utilizzare le opportune
+individuare qual è quello che deve essere usato, ed utilizzare le opportune
variabili.
La gran parte delle opzioni utilizzano per \param{optval} un valore intero, se
usato per \param{optval} ed una breve descrizione del significato delle
singole opzioni sulla sesta.
-
-Dato che le descrizioni di tab.~\ref{tab:sock_opt_socklevel} sono estremamente
-sommarie, vale la pena entrare in dettagli maggiori; questo ci consentirà
-anche di trattare i vari casi particolari, dato che nonostante queste opzioni
-siano indicate al livello generico, alcune di esse han senso solo per alcuni
-tipi di socket. L'elenco dettagliato del significato di ciascuna di esse è
-allora il seguente:
-\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{SO\_KEEPALIVE}] una connessione può restare attiva se non viene
- effettuato alcun traffico su di essa; in certi casi però può essere utile
- controllarne lo stato per accorgersi di eventuali problemi. Per questo, se
- si imposta questa opzione, è cura del kernel inviare degli appositi messaggi
- sulla rete (detti appunto \textit{keep-alive}) per verificare se la
- connessione è attiva. L'opzione funziona soltanto con socket che supportino
- le connessioni (non ha senso per socket UDP ad esempio), ed utilizza per
- \param{optval} un intero usato come valore logico.
-
- L'opzione si applica principalmente ai socket TCP. Con le impostazioni di
- default (che sono riprese da BSD) Linux emette un messaggio di
- \textit{keep-alive} verso l'altro capo della connessione se questa è rimasta
- senza traffico per più di due ore. Se è tutto a posto il messaggio viene
- ricevuto e verrà emesso un segmento ACK di risposta, alla cui ricezione
- ripartirà un'altro ciclo di attesa per altre due ore di inattività; tutto
- ciò viene effettuato dal kernel e le applicazioni non riceveranno nessun
- dato.
-
- In caso di problemi invece si possono avere i due casi già illustrati in
- sez.~\ref{sec:TCP_conn_crash} per il caso di terminazione prococe del
- server: il primo è quello in cui la macchina remota è caduta ed è stata
- riavviata, per cui dopo il riavvio la connessione non viene più
- riconosciuta,\footnote{si ricordi che un normale riavvio non ha questo
- effetto, in quanto si passa per la chiusura del processo, che chiude anche
- il socket inviando un segmento FIN all'altro capo della connessione.} e si
- otterrà come risposta un RST. In tal caso il socket viene chiuso dopo aver
- impostato un errore \errcode{ECONNRESET}.
-
- Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
- più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di
- 75 secondi ad un massimo di 9 volte\footnote{entrambi questi valori possono
- essere opportunamente modificati con gli opportuni parametri illustrati in
- sez.~\ref{sec:sock_sysctl}, si tenga presente che però questo vale a
- livello di kernel ed i valori saranno applicati a \textsl{tutti} i
- socket.} (per un totale di 11 minuti e 15 secondi) dopo di che, se non si
- è ricevuta nessuna risposta, il socket viene chiuso dopo aver impostato un
- errore di \errcode{ETIMEDOUT}. Se invece si riceve in risposta ad uno di
- questi messaggi un pacchetto ICMP di destinazione irraggiungibile, verrà
- restituito l'errore corrispondente.
-
- In generale questa opzione serve per individuare una caduta della
- connessione,\footnote{il crash di un processo di nuovo comporta la chiusura
- di tutti i file che aveva aperti e la relativa emissione degli opportuni
- segmenti FIN nel caso dei socket.} e viene usata sui server per evitare di
- mantenere impegnate le risorse dedicate a trattare delle connessioni in
- realtà terminate. Abilitandola le connessioni effettivamente terminate
- vengono chiuse ed una \func{select} potrà rilevare la conclusione delle
- stesse e ricevere il relativo errore. Si tenga però presente che non si ha
- la certezza assoluta che un errore di \errcode{ETIMEDOUT} corrisponda ad una
- reale conclusione della connessione, il problema potrebbe essere dovuto ad
- un problema di routing che perduri per un tempo maggiore di quello impiegato
- nei vari tentativi di ritrasmissione del \textit{keep-alive}.
-
+Le descrizioni delle opzioni presenti in tab.~\ref{tab:sock_opt_socklevel}
+sono estremamente sommarie, è perciò necessario fornire un po' più di
+informazioni. Alcune opzioni inoltre hanno una notevole rilevanza nella
+gestione dei socket, e pertanto il loro utilizzo sarà approfondito
+separatamente in sez.~\ref{sec:sock_options_main}. Quello che segue è quindi
+soltanto un elenco più dettagliato della breve descrizione di
+tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\const{SO\_KEEPALIVE}] questa opzione abilita un meccanismo di verifica
+ della persistenza di una connessione associata al socket (ed è pertanto
+ effettiva solo sui socket che supportano le connessioni, ed è usata
+ principalmente con il TCP). L'opzione utilizza per \param{optval} un intero
+ usato come valore logico. Maggiori dettagli sul suo funzionamento sono
+ forniti in sez.~\ref{sec:sock_options_main}.
\item[\const{SO\_OOBINLINE}] se questa opzione viene abilitata i dati
\textit{out-of-band} vengono inviati direttamente nel flusso di dati del
supportino i dati \textit{out-of-band} (non ha senso per socket UDP ad
esempio), ed utilizza per \param{optval} un intero usato come valore logico.
-
\item[\const{SO\_RCVLOWAT}] questa opzione imposta il valore che indica il
numero minimo di byte che devono essere presenti nel buffer di ricezione
perché il kernel passi i dati all'utente, restituendoli ad una \func{read} o
essere cambiato; \func{getsockopt} leggerà questo valore mentre
\func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
-
\item[\const{SO\_SNDLOWAT}] questa opzione imposta il valore che indica il
numero minimo di byte che devono essere presenti nel buffer di scrittura
perché il kernel li invii al protocollo successivo, consentendo ad una
sempre 1 e non può essere cambiato; \func{getsockopt} leggerà questo valore
mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
-
\item[\const{SO\_RCVTIMEO}] l'opzione permette di impostare un tempo massimo
sulle operazioni di lettura da un socket, e prende per \param{optval} una
struttura di tipo \struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct})
sulle operazioni di scrittura su un socket, ed usa gli stessi valori di
\const{SO\_RCVTIMEO}. In questo caso però si avrà un errore di
\errcode{EAGAIN} o \errcode{EWOULDBLOCK} per le funzioni di scrittura
- \func{write}, \func{writev}, \func{send}, \func{sendfrom} e \func{sendmsg}
+ \func{write}, \func{writev}, \func{send}, \func{sendto} e \func{sendmsg}
qualora queste restino bloccate per un tempo maggiore di quello specificato.
\item[\const{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
state rimosse con il passaggio al 2.2; è consigliato correggere i programmi
piuttosto che usare questa funzione.
-\item[\const{SO\_PASSCRED}] questa opzione abilita sui socket unix-domain la
- ricezione dei messaggi di controllo di tipo \const{SCM\_CREDENTIALS}. Prende
- come \param{optval} un intero usato come valore logico.
+\item[\const{SO\_PASSCRED}] questa opzione abilita sui socket unix-domain
+ (vedi sez.~\ref{sec:unix_socket}) la ricezione dei messaggi di controllo di
+ tipo \const{SCM\_CREDENTIALS}. Prende come \param{optval} un intero usato
+ come valore logico.
\item[\const{SO\_PEERCRED}] questa opzione restituisce le credenziali del
processo remoto connesso al socket; l'opzione è disponibile solo per socket
sez.~\ref{sec:unix_socket_xxx}).
\item[\const{SO\_BINDTODEVICE}] questa opzione permette di \textsl{legare} il
- socket ad una particolare interfaccia interfaccia, in modo che esso possa
- ricevere ed inviare pacchetti solo su quella. L'opzione richiede per
- \param{optval} il puntatore ad una stringa contenente il nome
- dell'interfaccia (ad esempio \texttt{eth0}); se si utilizza una stringa
- nulla o un valore nullo per \param{optlen} si rimuove un precedente
- collegamento.
+ socket ad una particolare interfaccia, in modo che esso possa ricevere ed
+ inviare pacchetti solo su quella. L'opzione richiede per \param{optval} il
+ puntatore ad una stringa contenente il nome dell'interfaccia (ad esempio
+ \texttt{eth0}); utilizzando una stringa nulla o un valore nullo per
+ \param{optlen} si può rimuovere un precedente collegamento.
Il nome della interfaccia deve essere specificato con una stringa terminata
da uno zero e di lunghezza massima pari a \const{IFNAMSIZ}; l'opzione è
famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
socket} (vedi sez.~\ref{cha:advanced_socket_xxx}).
-
\item[\const{SO\_DEBUG}] questa opzione abilita il debugging delle operazioni
dei socket; l'opzione utilizza per \param{optval} un intero usato come
valore logico, e può essere utilizzata solo da un processo con i privilegi
di amministratore (in particolare con la \textit{capability}
\const{CAP\_NET\_ADMIN}). L'opzione necessita inoltre dell'opportuno
supporto nel kernel;\footnote{deve cioè essere definita la macro di
- preprocessore \texttt{SOCK\_DEBUGGING} nel file \file{include/net/sock.h}
+ preprocessore \macro{SOCK\_DEBUGGING} nel file \file{include/net/sock.h}
dei sorgenti del kernel, questo è sempre vero nei kernel delle serie
superiori alla 2.3, per i kernel delle serie precedenti invece è
necessario aggiungere a mano detta definizione; è inoltre possibile
abilitare anche il tracciamento degli stati del TCP definendo la macro
- \texttt{STATE\_TRACE} in \file{include/net/tcp.h}.} quando viene
+ \macro{STATE\_TRACE} in \file{include/net/tcp.h}.} quando viene
abilitata una serie di messaggi con le informazioni di debug vengono inviati
direttamente al sistema del kernel log.\footnote{si tenga presente che il
comportamento è diverso da quanto avviene con BSD, dove l'opzione opera
programma, \cmd{trpt}.}
\item[\const{SO\_REUSEADDR}] questa opzione permette di eseguire la funzione
- \func{bind} su indirizzi locali che siano già in uso; l'opzione utilizza per
- \param{optval} un intero usato come valore logico. Questa opzione modifica
- il comportamento normale dell'interfaccia dei socket che fa fallire
- l'esecuzione della funzione \func{bind} con un errore di
+ \func{bind} su indirizzi locali che siano già in uso da altri socket;
+ l'opzione utilizza per \param{optval} un intero usato come valore logico.
+ Questa opzione modifica il comportamento normale dell'interfaccia dei socket
+ che fa fallire l'esecuzione della funzione \func{bind} con un errore di
\errcode{EADDRINUSE} quando l'indirizzo locale\footnote{più propriamente il
controllo viene eseguito sulla porta.} è già in uso da parte di un altro
- socket.
-
- Come Stevens sottolinea in \cite{UNP1} si distinguono quattro casi per
- l'utilizzo di questa opzione; il primo è quello in cui un server è terminato
- ma esistono ancora dei processi figli che mantengono attiva almeno una
- connessione remota che utilizza l'indirizzo locale; quando si riavvia il
- server questo viene bloccato sulla chiamata a \func{bind} dato che la porta
- è ancora utilizzata in una connessione esistente.\footnote{questa è una
- delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
- quanto è piuttosto comune in questa situazione quando si sta sviluppando
- un server che si ferma e si riavvia in continuazione.} Inoltre se si usa
- il protocollo TCP questo può avvenire anche dopo che l'ultimo processo
- figlio è terminato, dato che la connessione può restare attiva anche dopo la
- chiusura del socket mantenendosi nello stato \texttt{TIME\_WAIT}.
-
- Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
- \func{bind} si consente a quest'ultima di avere comunque successo anche se
- la connessione è attiva (o nello stato texttt{TIME\_WAIT}). È bene però
- ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
- presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si
- usa questa opzione esiste sempre una probabilità, anche se estremamente
- remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
- indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
- numeri di sequenza dei pacchetti, e questo è estremamente improbabile.}
- che eventuali pacchetti rimasti intrappolati in una precedente connessione
- possano finire fra quelli di una nuova.
-
- Il secondo caso in cui viene usata questa opzione è quando si ha una
- macchina cui sono assegnati diversi numeri IP (o come suol dirsi
- \textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
- programma diverso (o una istanza diversa dello stesso programma) per
- indirizzi IP diversi. Si ricordi infatti che è sempre possibile indicare a
- \func{bind} di collegarsi solo su di un indirizzo specifico; in tal caso se
- un altro programma cerca di riutilizzare la stessa porta (anche specificando
- un indirizzo diverso) otterrà un errore a meno di non aver preventivamente
- impostato \const{SO\_REUSEADDR}. Usando questa opzione diventa anche
- possibile eseguire \func{bind} sull'indirizzo generico, e questo permetterà
- il collegamento per tutti gli indirizzi (di quelli presenti) per i quali la
- porta risulti libera. Infine si tenga presente che con il protocollo TCP non
- è mai possibile far partire server che eseguano \func{bind} sullo stesso
- indirizzo e la stessa porta, cioè ottenere quello che viene chiamato un
- \textit{completely duplicate binding}.
-
- Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
- all'interno dello stesso programma per associare indirizzi diversi a socket
- diversi. Vale in questo caso quanto detto in precedenza, l'unica differenza
- è che in questo caso le diverse chiamate a \func{bind} sono eseguite
- all'interno dello stesso programma.
-
+ socket. Maggiori dettagli sul suo funzionamento sono forniti in
+ sez.~\ref{sec:sock_options_main}.
\item[\const{SO\_TYPE}] questa opzione permette di leggere il tipo di socket
su cui si opera; funziona solo con \func{getsockopt}, ed utilizza per
\item[\const{SO\_DONTROUTE}] questa opzione forza l'invio diretto dei
pacchetti del socket, saltando ogni processo relativo all'uso della tabella
- di routing del kernel. Prende come \param{optval} un intero usato come
- valore logico.
+ di routing del kernel. Prende per \param{optval} un intero usato come valore
+ logico.
+
+\item[\const{SO\_BROADCAST}] questa opzione abilita il \textit{broadcast};
+ quanto abilitata i socket di tipo \const{SOCK\_DGRAM} riceveranno i
+ pacchetti inviati all'indirizzo di broadcast, e potranno scrivere pacchetti
+ su tale indirizzo. Prende per \param{optval} un intero usato come valore
+ logico. L'opzione non ha effetti su un socket di tipo \const{SOCK\_STREAM}.
+
+\item[\const{SO\_SNDBUF}] questa opzione imposta la dimenzione del buffer di
+ uscita del socket. Prende per \param{optval} un intero indicante il numero
+ di byte. Il valore di default ed il valore massimo che si può specificare
+ come argomento per questa opzione sono impostabili tramiti gli opportuni
+ valori di \func{sysctl} (vedi sez.~\ref{sec:sock_sysctl}).
+
+\item[\const{SO\_RCVBUF}] questa opzione imposta la dimenzione del buffer di
+ ingresso del socket. Prende per \param{optval} un intero indicante il numero
+ di byte. Il valore di default ed il valore massimo che si può specificare
+ come argomento per questa opzione sono impostabili tramiti gli opportuni
+ valori di \func{sysctl} (vedi sez.~\ref{sec:sock_sysctl}).
+
+\item[\const{SO\_LINGER}] questa opzione controlla le modalità con cui viene
+ chiuso un socket quando si utilizza un protocollo che supporta le
+ connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
+ modifica il comportamento delle funzioni \func{close} e \func{shutdown}.
+ L'opzione richiede che l'argomento \param{optval} sia una struttura di tipo
+ \struct{linger}, definita in \texttt{sys/socket.h} ed illustrata in
+ fig.~\ref{fig:sock_linger_struct}. Maggiori dettagli sul suo funzionamento
+ sono forniti in sez.~\ref{sec:sock_options_main}.
+
+\item[\const{SO\_PRIORITY}] questa opzione permette di impostare le priorità
+ per tutti i pacchetti che sono inviati sul socket, prende per \param{optval}
+ un valore intero. Con questa opzione il kernel usa il valore per ordinare le
+ priorità sulle code di rete,\footnote{questo richiede che sia abilitato il
+ sistema di \textit{Quality of Service} disponibile con le opzioni di
+ routing avanzato.} i pacchetti con priorità più alta vengono processati
+ per primi, in modalità che dipendono dalla disciplina di gestione della
+ coda. Nel caso di protocollo IP questa opzione permette anche di impostare i
+ valori del campo \textit{type of service} (noto come TOS, vedi
+ sez.~\ref{sec:IP_header}) per i pacchetti uscenti. Per impostare una
+ priorità al di fuori dell'intervallo di valori fra 0 e 6 sono richiesti i
+ privilegi di amministratore con la capability \const{CAP\_NET\_ADMIN}.
+
+\item[\const{SO\_ERROR}] questa opzione riceve un errore presente sul socket;
+ può essere utilizzata soltanto con \func{getsockopt} e prende per
+ \param{optval} un valore intero.
+\end{basedescript}
+
+
+\subsection{L'uso delle principali opzioni dei socket}
+\label{sec:sock_options_main}
+
+La descrizione sintetica del significato delle opzioni generiche dei socket,
+riportata nell'elenco in sez.~\ref{sec:sock_generic_options}, è
+necessariamente sintentica, alcune di queste però possono essere utilizzate
+per controllare delle funzionalità che hanno una notevole rilevanza nella
+programmazione dei socket. Per questo motivo faremo in questa sezione un
+approfondimento sul significato delle opzioni generiche più importanti.
+
+
+\index{\texttt{SO\_KEEPALIVE} (costante)|(}
+\subsubsection{L'opzione \const{SO\_KEEPALIVE}}
+
+La prima opzione da approfondire è \const{SO\_KEEPALIVE} che permette di
+tenere sotto controllo lo stato di una connessione. Una connessione infatti
+resta attiva anche quando non viene effettuato alcun traffico su di essa,
+questo può comportare che un crollo della connessione, qualora avvenisse ad
+esempio in conseguenza di una interruzione completa della rete, potrebbe
+passare inosservato.
+
+Se si imposta questa opzione, è invece cura del kernel inviare degli appositi
+messaggi sulla rete, detti appunto \textit{keep-alive}, per verificare se la
+connessione è attiva. L'opzione funziona soltanto con socket che supportino
+le connessioni (non ha senso per socket UDP ad esempio) e si applica
+principalmente ai socket TCP.
+
+Con le impostazioni di default (che sono riprese da BSD) Linux emette un
+messaggio di \textit{keep-alive}\footnote{in sostanza un segmento ACK vuoto,
+ cui sarà risposto con un altro segmento ACK vuoto.} verso l'altro capo della
+connessione se questa è rimasta senza traffico per più di due ore. Se è tutto
+a posto il messaggio viene ricevuto e verrà emesso un segmento ACK di
+risposta, alla cui ricezione ripartirà un'altro ciclo di attesa per altre due
+ore di inattività; il tutto avviene all'interno del kernel e le applicazioni
+non riceveranno nessun dato.
+
+In caso di problemi invece si possono avere i due casi già illustrati in
+sez.~\ref{sec:TCP_conn_crash} per il caso di terminazione prococe del server:
+il primo è quello in cui la macchina remota è caduta ed è stata riavviata, per
+cui dopo il riavvio la connessione non viene più riconosciuta,\footnote{si
+ ricordi che un normale riavvio non ha questo effetto, in quanto in tal caso
+ si passa per la chiusura del processo, e questo, come illustrato in
+ sez.~\ref{sec:file_close}, comporta la chiusura del socket col'invio di un
+ segmento FIN all'altro capo della connessione, che verrà regolarmente
+ chiusa.} in questo caso all'invio del messaggio di \textit{keep-alive} si
+otterrà come risposta un segmento RST che indica che l'altro capo non
+riconosce più l'esistenza della connessione. In tal caso il socket viene
+chiuso dopo aver impostato un errore \errcode{ECONNRESET}.
+
+Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
+più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di 75
+secondi per un massimo di 9 volte\footnote{entrambi questi valori possono
+ essere opportunamente modificati con gli opportuni parametri illustrati in
+ sez.~\ref{sec:sock_sysctl}, si tenga presente che però questo vale a livello
+ di kernel ed i suddetti valori saranno applicati a \textsl{tutti} i socket.}
+(per un totale di 11 minuti e 15 secondi) dopo di che, se non si è ricevuta
+nessuna risposta, il socket viene chiuso dopo aver impostato un errore di
+\errcode{ETIMEDOUT}. Qualora la connessione si sia ristabilita e si riceva un
+successivo messaggio di risposta il ciclo riparte come se niente fosse
+avvenuto. Infine se invece si riceve come risposta un pacchetto ICMP di
+destinazione irraggiungibile (vedi sez.~\ref{sec:icmp_protocol_xxx}), verrà
+restituito l'errore corrispondente.
+
+In generale questa opzione serve per individuare una caduta della connessione
+anche quando non si sta facendo traffico su di essa. Viene usata
+principalmente sui server per evitare di mantenere impegnate le risorse che
+verrbbero dedicate a trattare delle connessioni che in realtà sono già
+terminate (quelle che vengono anche chiamate connessioni
+\textsl{semi-aperte}); in tutti quei casi cioè in cui il server si trova in
+attesa di dati in ingresso su una connessione che non arriveranno mai perché o
+il client sull'altro capo non è più attivo o non è più in grado di comunicare
+con il server via rete.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/TCP_echod_fourth.c}
+ \end{minipage}
+ \normalsize
+ \caption{La sezione della nuova versione del server del servizio
+ \textit{echo} che prevede l'attivazione del \textit{keepalive} sui
+ socket.}
+ \label{fig:echod_keepalive_code}
+\end{figure}
+
+Abilitandola dopo un certo tempo le connessioni effettivamente terminate
+verrano comunque chiuse per cui, utilizzando ad esempio una \func{select}, se
+be potrà rilevare la conclusione e ricevere il relativo errore. Si tenga
+presente però che non può avere la certezza assoluta che un errore di
+\errcode{ETIMEDOUT} ottenuto dopo aver abilitato questa opzione corrisponda
+necessariamente ad una reale conclusione della connessione, il problema
+potrebbe anche essere dovuto ad un problema di routing che perduri per un
+tempo maggiore di quello impiegato nei vari tentativi di ritrasmissione del
+\textit{keep-alive} (anche se questa non è una una condizione molto
+probabile).
+
+Come esempio dell'utilizzo di questa opzione introduciamo all'interno del
+nostro server per il servizio \textit{echo} la nuova opzione \texttt{-k} che
+permette di attivare il \textit{keep-alive} sui socket; tralasciando la parte
+relativa alla gestione di detta opzione (che si limita ad assegnare ad 1 la
+variabile \var{keepalive}) tutte le modifiche al server sono riportate in
+fig.~\ref{fig:echod_keepalive_code}. Al solito il codice completo è contenuto
+nel file \texttt{TCP\_echod\_fourth.c} dei sorgenti allegati alla guida.
+
+Come si può notare la variabile \var{keepalive} è preimpostata (\texttt{\small
+ 8}) ad un valore nullo; essa viene utilizzata sia come variabile logica per
+la condizione (\texttt{\small 14}) che controlla l'attivazione del
+\textit{keep-alive} che come valore dell'argomento \param{optval} della
+chiamata a \func{setsockopt} (\texttt{\small 16}). A seconda del suo valore
+tutte le volte che un processo figlio viene eseguito in risposta ad una
+connessione verrà pertanto eseguita o meno la sezione (\texttt{\small 14--17})
+che esegue l'impostazione di \const{SO\_KEEPALIVE} sul socket connesso,
+attivando il relativo comportamento.
+\index{\texttt{SO\_KEEPALIVE} (costante)|)}
+
+
+\index{\texttt{SO\_REUSEADDR} (costante)|(}
+\subsubsection{L'opzione \const{SO\_REUSEADDR}}
+
+La seconda opzione da approfondire è \const{SO\_REUSEADDR}, che consente di
+eseguire \func{bind} su un socket anche quando la porta specificata è già in
+uso da parte di un altro socket. Si ricordi infatti che, come accennato in
+sez.~\ref{sec:TCP_func_bind}, normalmente la funzione \func{bind} fallisce con
+un errore di \errcode{EADDRINUSE} se la porta scelta è già utilizzata da un
+altro socket, proprio per evitare che possano essere lanciati due server sullo
+stesso indirizzo e la stessa porta, che verrebbero a contendersi i pacchetti
+aventi quella destinazione.
+
+Esistono però situazioni ed esigenze particolari in cui non si vuole che
+questo comportamento di salvaguardia accada, ed allora si può fare ricorso a
+questa opzione. La questione è comunque abbastanza complessa in quanto, come
+sottolinea Stevens in \cite{UNP1}, si distinguono ben quattro casi diversi in
+cui è prevista la possibilità di un utilizzo di questa opzione, il che la
+rende una delle più difficili da capire.
+
+Il primo caso, che è anche il più comune, in cui si fa ricorso a
+\const{SO\_REUSEADDR} è quello in cui un server è terminato ma esistono ancora
+dei processi figli che mantengono attiva almeno una connessione remota che
+utilizza l'indirizzo locale, mantenendo occupata la porta. Quando si riesegue
+il server allora questo riceve un errore sulla chiamata a \func{bind} dato che
+la porta è ancora utilizzata in una connessione esistente.\footnote{questa è
+ una delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
+ quanto è piuttosto comune trovarsi in questa situazione quando si sta
+ sviluppando un server che si ferma e si riavvia in continuazione dopo aver
+ fatto modifiche.} Inoltre se si usa il protocollo TCP questo può avvenire
+anche dopo tutti i processi figli sono terminati, dato che una connessione può
+restare attiva anche dopo la chiusura del socket, mantenendosi nello stato
+\texttt{TIME\_WAIT} (vedi sez.~\ref{sec:TCP_time_wait}).
+
+Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
+\func{bind} si consente a quest'ultima di avere comunque successo anche se la
+connessione è attiva (o nello stato \texttt{TIME\_WAIT}). È bene però
+ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
+presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si usa
+questa opzione esiste sempre una probabilità, anche se estremamente
+remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
+ indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
+ numeri di sequenza dei pacchetti, e questo è estremamente improbabile.} che
+eventuali pacchetti rimasti intrappolati in una precedente connessione possano
+finire fra quelli di una nuova.
+
+Come esempio di uso di questa connessione abbiamo predisposto una nuova
+versione della funzione \func{sockbind} (vedi fig.~\ref{fig:sockbind_code})
+che consenta l'impostazione di questa opzione. La nuova funzione è
+\func{sockbindopt}, e le principali differenze rispetto alla precedente sono
+illustrate in fig.~\ref{fig:sockbindopt_code}, dove si sono riportate le
+sezioni di codice modificate rispetto alla versione precedente. Il codice
+completo della funzione si trova, insieme alle altre funzioni di servizio dei
+socket, all'interno del file \texttt{SockUtils.c} dei sorgenti allegati alla
+guida.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sockbindopt.c}
+ \end{minipage}
+ \normalsize
+ \caption{Le sezioni della funzione \func{sockbindopt} modificate rispetto al
+ codice della precedente \func{sockbind}.}
+ \label{fig:sockbindopt_code}
+\end{figure}
+
+In realtà tutto quello che si è fatto è stato introdurre nella nuova funzione
+(\texttt{\small 1}) un nuovo argomento intero, \param{reuse}, che conterrà il
+valore logico da usare nella successiva chiamata (\texttt{\small 14}) a
+\func{setsockopt}. Si è poi aggiunta una sezione (\texttt{\small 13-17}) che
+esegue l'impostazione dell'opzione fra la chiamata a \func{socket} e quella a
+\func{bind}.
+
+
+A questo punto basterà modificare il server per utilizzare la nuova
+funzione; in fig.~\ref{fig:TCP_echod_fifth} abbiamo riportato le sezioni
+modificate rispetto alla precedente versione di
+fig.~\ref{fig:TCP_echod_third}. Al solito il codice completo è coi sorgenti
+allegati alla guida, nel file \texttt{TCP\_echod\_fifth.c}.
+
+Anche in questo caso si è introdotta (\texttt{\small 8}) una nuova variabile
+\var{reuse} che consente di controllare l'uso dell'opzione e che poi sarà
+usata (\texttt{\small 14}) come ultimo argomento di \func{setsockopt}. Il
+valore di default di questa variabile è nullo, ma usando l'opzione \texttt{-r}
+nell'invocazione del server (al solito la gestione delle opzioni non è
+riportata in fig.~\ref{fig:TCP_echod_fifth}) se ne potrà impostare ad 1 il
+valore, per cui in tal caso la successiva chiamata (\texttt{\small 13-17}) a
+\func{setsockopt} attiverà l'opzione \const{SO\_REUSEADDR}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/TCP_echod_fifth.c}
+ \end{minipage}
+ \normalsize
+ \caption{Il nuovo codice per l'apertura passiva del server \textit{echo} che
+ usa la nuova funzione \func{sockbindopt}.}
+ \label{fig:TCP_echod_fifth}
+\end{figure}
+
+Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
+macchina cui sono assegnati diversi numeri IP (o come suol dirsi
+\textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
+programma diverso (o una istanza diversa dello stesso programma) per indirizzi
+IP diversi. Si ricordi infatti che è sempre possibile indicare a \func{bind}
+di collegarsi solo su di un indirizzo specifico; in tal caso se un altro
+programma cerca di riutilizzare la stessa porta (anche specificando un
+indirizzo diverso) otterrà un errore, a meno di non aver preventivamente
+impostato \const{SO\_REUSEADDR}.
+
+Usando questa opzione diventa anche possibile eseguire \func{bind}
+sull'indirizzo generico, e questo permetterà il collegamento per tutti gli
+indirizzi (di quelli presenti) per i quali la porta non risulti occupata da
+una precedente chiamata più specifica. Infine si tenga presente che con il
+protocollo TCP non è mai possibile far partire server che eseguano \func{bind}
+sullo stesso indirizzo e la stessa porta, cioè ottenere quello che viene
+chiamato un \textit{completely duplicate binding}.
+
+Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
+all'interno dello stesso programma per associare indirizzi locali diversi a
+socket diversi. In genere questo viene fatto per i socket UDP quando è
+necessario ottenere l'indirizzo a cui sono rivolte le richieste del client ed
+il sistema non supporta l'opzione \const{IP\_RECVDSTADDR};\footnote{nel caso
+ di Linux questa opzione è stata supportata per in certo periodo nello
+ sviluppo del kernel 2.1.x, ma è in seguito stata soppiantata dall'uso di
+ \const{IP\_PKTINFO} (vedi sez.~\ref{sec:sock_ipv4_options}).} in tale modo
+si può sapere a quale socket corrisponde un certo indirizzo. Non ha senso
+fare questa operazione per un socket TCP dato che su di essi si può sempre
+invocare \func{getsockname} una volta che si è completata la connessione.
+
+Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
+\textit{completely duplicate binding}, quando cioè si vuole eseguire
+\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
+altro socket. Questo ovviamente non ha senso per il normale traffico di rete,
+in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma
+quando un sistema supporta il traffico in multicast, in cui una applicazione
+invia i pacchetti a molte altre (vedi sez.~\ref{sec:multicast_xxx}), allora ha
+senso che su una macchina i pacchetti provenienti dal traffico in multicast
+possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
+ traffico in multicast è quello di uno streaming di dati (audio, video,
+ ecc.), l'uso del multicast consente in tal caso di trasmettere un solo
+ pacchetto, che potrà essere ricevuto da tutti i possibili destinatari
+ (invece di inviarne un duplicato a ciascuno); in questo caso è perfettamente
+ logico aspettarsi che sulla stessa macchina più utenti possano lanciare un
+ programma che permetta loro di ricevere gli stessi dati.} o da diverse
+istanze della stessa applicazione.
+
+In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una
+applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
+un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
+la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di
+applicazione è normale l'uso del protovollo UDP). La regola è che quando si
+hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
+tutti pacchetti destinati ad un indirizzo di broadcast o di multicast viene
+inviata una copia a ciascuna applicazione. Non è definito invece cosa accade
+qualora il pacchetto sia destinato ad un indirizzo normale (unicast).
+
+Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
+introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta
+opzione sia specificata per tutti i socket per i quali si vuole eseguire il
+\textit{completely duplicate binding}. Nel caso di Linux questa opzione non
+esiste, ma il comportamento di \const{SO\_REUSEADDR} è analogo, sarà cioè
+possibile effettuare un \textit{completely duplicate binding} ed ottenere il
+successo di \func{bind} su un socket legato allo stesso indirizzo e porta solo
+se il programma che ha eseguito per primo \func{bind} su di essi ha impostato
+questa opzione.\footnote{Questa restrizione permette di evitare il cosiddetto
+ \textit{port stealing}, in cui un programma, usando \const{SO\_REUSEADDR},
+ può collegarsi ad una porta già in uso e ricevere i pacchetti destinati ad
+ un altro programma; con questa caratteristica ciò è possibile soltanto se il
+ primo programma a consentirlo, avendo usato fin dall'inizio
+ \const{SO\_REUSEADDR}.}
+
+\index{\texttt{SO\_REUSEADDR} (costante)|)}
+
+
+\index{\texttt{SO\_LINGER} (costante)|(}
+\subsubsection{L'opzione \const{SO\_LINGER}}
+
+La terza opzione da approfondire è \const{SO\_LINGER}; essa, come il nome
+suggerisce, consente di ``\textsl{indugiare}'' nella chiusura di un socket. Il
+comportamento standard sia di \func{close} che \func{shutdown} è infatti
+quello di terminare immediatamente dopo la chiamata, mentre il procedimento di
+chiusura della connessione (o di un lato di essa) ed il rispettivo invio sulla
+rete di tutti i dati ancora presenti nei buffer, viene gestito in sottofondo
+dal kernel.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/linger.h}
+ \end{minipage}
+ \caption{La struttura \structd{linger} richiesta come valore dell'argomento
+ \param{optval} per l'impostazione dell'opzione dei socket
+ \const{SO\_LINGER}.}
+ \label{fig:sock_linger_struct}
+\end{figure}
+
+L'uso di \const{SO\_LINGER} con \func{setsockopt} permette di modificare (ed
+eventualmente ripristinare) questo comportamento in base ai valori passati nei
+campi della stuttura \struct{linger}, illustrata in
+fig.~\ref{fig:sock_linger_struct}. Fintanto che il valore del campo
+\var{l\_onoff} di \struct{linger} è nullo la modalità che viene impostata
+(qualunque sia il valore di \var{l\_linger}) è quella standard appena
+illustrata; questa combinazione viene utilizzata per riportarsi al
+comportamento normale qualora esso sia stato cambiato da una precedente
+chiamata.
+
+Se si utilizza un valore di \var{l\_onoff} diverso da zero, il comportamento
+alla chiusura viene a dipendere dal valore specificato per il campo
+\var{l\_linger}; se quest'ultimo è nullo l'uso delle funzioni \func{close} e
+\func{shutdown} provoca la terminazione immediata della connessione: nel caso
+di TCP cioè non viene eseguito il procedimento di chiusura illustrato in
+sez.~\ref{sec:TCP_conn_term}, ma tutti i dati ancora presenti nel buffer
+vengono immediatamente scartati e sulla rete viene inviato un segmento di RST
+che termina immediatamente la connessione.
+
+Un esempio di questo comportamento si può abilitare nel nostro client del
+servizio \textit{echo} utilizzando l'opzione \texttt{-r}; riportiamo in
+fig.~\ref{fig:TCP_echo_sixth} la sezione di codice che permette di introdurre
+questa funzionalità,; al solito il codice completo è disponibile nei sorgenti
+allegati.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/TCP_echo_sixth.c}
+ \end{minipage}
+ \normalsize
+ \caption{La sezione del codice del client \textit{echo} che imposta la
+ terminazione immediata della connessione in caso di chiusura.}
+ \label{fig:TCP_echo_sixth}
+\end{figure}
+
+La sezione indicata viene eseguita dopo aver effettuato la connessione e prima
+di chiamare la funzione di gestione, cioè fra le righe (\texttt{\small 12}) e
+(\texttt{\small 13}) del precedente esempio di fig.~\ref{fig:TCP_echo_fifth}.
+Il codice si limita semplicememente a controllare (\texttt{\small 3}) il
+valore della variabile \var{reset} che assegnata nella gestione delle opzioni
+in corrispondenza all'uso di \texttt{-r} nella chiamata del client. Nel caso
+questa sia diversa da zero vengono impostati (\texttt{\small 5--6}) i valori
+della struttura \var{ling} che permettono una terminazione immediata della
+connessine. Questa viene poi usata nella successiva (\texttt{\small 7})
+chiamata a \func{setsockopt}. Al solito si controlla (\texttt{\small 7--10})
+il valore di ritorno e si termina il programma in caso di errore, stampadone
+il valore.
+
+Infine l'ultima possibilità, quella in cui si utilizza effettivamente
+\const{SO\_LINGER} per \textsl{indugiare} nella chiusura, è quella in cui sia
+\var{l\_onoff} che \var{l\_linger} hanno un valore diverso da zero. Se si
+esegue l'impostazione con questi valori sia \func{close} che \func{shutdown}
+si bloccano, nel frattempo viene eseguita la normale procedura di conclusione
+della connessione (quella di sez.~\ref{sec:TCP_conn_term}) ma entrambe le
+funzioni non ritornano fintanto che non si sia concluso il procedimento di
+chiusura della connessione, o non sia passato un numero di
+secondi\footnote{questa è l'unità di misura indicata da POSIX ed adottata da
+ Linux, altri kernel possono usare unità di misura diverse, oppure usare il
+ campo \var{l\_linger} come valore logico (ignorandone il valore) per rendere
+ (quando diverso da zero) \func{close} e \func{shutdown} bloccanti fino al
+ completamento della trasmissione dei dati sul buffer.} pari al valore
+specificato in \var{l\_linger}.
-\item[\const{SO\_BROADCAST}]
-\item[\const{SO\_SNDBUF}]
+\index{\texttt{SO\_LINGER} (costante)|)}
-\item[\const{SO\_RCVBUF}]
-\item[\const{SO\_LINGER}]
-\item[\const{SO\_PRIORITY}]
-\item[\const{SO\_ERROR}]
+\subsection{Le opzioni per il protocollo IPv4}
+\label{sec:sock_ipv4_options}
+
+Il secondo insieme di opzioni dei socket che tratteremo è quello relativo ai
+socket che usano il protocollo IPv4.\footnote{come per le precedenti opzioni
+ generiche una descrizione di esse è disponibile nella settima sezione delle
+ pagine di manuale, nel caso specifico la documentazione si può consultare
+ con \texttt{man 7 ip}.} Se si vuole operare su queste opzioni generiche il
+livello da utilizzare è \const{SOL\_IP}; si è riportato un elenco di queste
+opzioni in tab.~\ref{tab:sock_opt_iplevel}. Le costanti indicanti le opzioni e
+tutte le altre costanti ad esse collegate sono definite in
+\file{netinet/ip.h}, ed accessibili includendo detto file.
+
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|c|c|c|l|l|}
+ \hline
+ \textbf{Opzione}&\texttt{get}&\texttt{set}&\textbf{flag}&\textbf{Tipo}&
+ \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{IP\_OPTIONS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta o riceve le opzioni di IP.\\
+ \const{IP\_PKTINFO} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio di informazione.\\
+ \const{IP\_RECVTOS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio col campo TOS.\\
+ \const{IP\_RECVTTL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio col campo TTL.\\
+ \const{IP\_RECVOPTS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio con le opzioni IP.\\
+ \const{IP\_RETOPTS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio con le opzioni IP non trattate.\\
+ \const{IP\_TOS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta il valore del campo TOS.\\
+ \const{IP\_TTL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta il valore del campo TTL.\\
+ \const{IP\_HDRINCL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa l'intestazione di IP nei dati.\\
+ \const{IP\_RECVERR} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita la gestione degli errori.\\
+ \const{IP\_MTU\_DISCOVER} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta il Path MTU Discovery.\\
+ \const{IP\_MTU} &$\bullet$& &$\bullet$&\texttt{int}&
+ Legge il valore attuale della MTU.\\
+ \const{IP\_ROUTER\_ALERT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta l'opzione \textit{IP router alert} sui pacchetti.\\
+ \const{IP\_MULTICAST\_TTL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta il TTL per i pacchetti multicast.\\
+ \const{IP\_MULTICAST\_LOOP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Controlla il reinvio a se stessi dei dati di multicast.\\
+ \const{IP\_ADD\_MEMBERSHIP} & &$\bullet$&$\bullet$&\texttt{int}&
+ Si unisce a un gruppo di multicast.\\
+ \const{IP\_DROP\_MEMBERSHIP}& &$\bullet$&$\bullet$&\texttt{int}&
+ Si sgancia da un gruppo di multicast.\\
+ \const{IP\_MULTICAST\_IF} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta l'interfaccia locale di un socket multicast.\\
+ \hline
+ \end{tabular}
+ \caption{Le opzioni disponibili al livello \const{SOL\_IP}.}
+ \label{tab:sock_opt_iplevel}
+\end{table}
+
+Le descrizioni di tab.~\ref{tab:sock_opt_iplevel} sono estremamente succinte,
+una maggiore quantità di dettagli su queste opzioni è fornito nel seguente
+elenco:
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+
+
+\item[\const{IP\_OPTIONS}] l'opzione permette di impostare o leggere le
+ opzioni del protocollo IP (si veda sez.~\ref{sec:IP_options}). L'opzione
+ prende come valore dell'argomento \param{optval} un puntatore ad un buffer
+ dove sono mantenute le opzioni, mentre \param{optlen} indica la dimensione
+ di quest'ultimo. Quando la si usa con \func{getsockopt} vengono lette le
+ opzioni IP utilizzate per la spedizione, quando la si usa con
+ \func{setsockopt} vengono impostate le opzioni specificate. L'uso di questa
+ opzione richiede una profonda conoscenza del funzionamento del protocollo,
+ torneremo in parte sull'argomento in sez.~\ref{sec:sock_advanced_xxx}.
+
+
+\item[\const{IP\_PKTINFO}] Quando abilitata l'opzione permette di ricevere
+ insieme ai pacchetti un messaggio ancillare (vedi
+ sez.~\ref{sec:TCP_ancillary_data}) di tipo \const{IP\_PKTINFO} contenente
+ una struttura \struct{pktinfo} (vedi fig.~\ref{fig:sock_pktinfo_struct}) che
+ mantiene una serie di informazioni riguardo i pacchetti in arrivo. In
+ particolare è possibile conoscere l'interfaccia su cui è stato ricevuto un
+ pacchetto (nel campo \var{ipi\_ifindex}), l'indirizzo locale da esso
+ utilizzato (nel campo \var{ipi\_spec\_dst}) e l'indirizzo remoto dello
+ stesso (nel campo \var{ipi\_addr}).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/pktinfo.h}
+ \end{minipage}
+ \caption{La struttura \structd{pktinfo} usata dall'opzione
+ \const{IP\_PKTINFO} per ricavare informazioni sui pacchetti di un socket
+ di tipo \const{SOCK\_DGRAM}.}
+ \label{fig:sock_pktinfo_struct}
+\end{figure}
+
+
+L'opzione è utilizzabile solo per socket di tipo \const{SOCK\_DGRAM}. Questa è
+una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
+Linux;\footnote{non dovrebbe pertanto essere utilizzata se si ha a cuore la
+ portabilità.} essa permette di sostituire le opzioni \const{IP\_RECVDSTADDR}
+e \const{IP\_RECVIF} presenti in altri Unix (la relativa informazione è quella
+ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
+\struct{pktinfo}).
+
+
+\item[\const{IP\_RECVTOS}] Quando abilitata l'opzione permette di ricevere
+ insieme ai pacchetti un messaggio ancillare di tipo \const{IP\_TOS}, che
+ contiene un byte con il valore del campo \textit{Type of Service}
+ dell'intestazione IP del pacchetto stesso (vedi sez.~\ref{sec:IP_header}).
+ Prende per \param{optval} un intero usato come valore logico.
+
+\item[\const{IP\_RECVTTL}] Quando abilitata l'opzione permette di ricevere
+ insieme ai pacchetti un messaggio ancillare di tipo \const{IP\_RECVTTL},
+ contenente un byte con il valore del campo \textit{Time to Live}
+ dell'intestazione IP (vedi sez.~\ref{sec:IP_header}). L'opzione richiede
+ per \param{optval} un intero usato come valore logico. L'opzione non è
+ supportata per socket di tipo \const{SOCK\_STREAM}.
+
+\item[\const{IP\_RECVOPTS}] Quando abilitata l'opzione permette di ricevere
+ insieme ai pacchetti un messaggio ancillare di tipo \const{IP\_OPTIONS},
+ contenente le opzioni IP del protocollo (vedi sez.~\ref{sec:IP_options}). Le
+ intestazioni di instradamento e le altre opzioni sono già riempite con i
+ dati locali. L'opzione richiede per \param{optval} un intero usato come
+ valore logico. L'opzione non è supportata per socket di tipo
+ \const{SOCK\_STREAM}.
+
+\item[\const{IP\_RETOPTS}] Identica alla precedente \const{IP\_RECVOPTS}, ma
+ in questo caso restituisce i dati grezzi delle opzioni, senza che siano
+ riempiti i capi di instradamento e le marche temporali. L'opzione richiede
+ per \param{optval} un intero usato come valore logico. L'opzione non è
+ supportata per socket di tipo \const{SOCK\_STREAM}.
+
+
+\item[\const{IP\_TOS}] L'opzione consente di leggere o impostare il campo
+ \textit{Type of Service} dell'intestazione IP (vedi
+ sez.~\ref{sec:IP_header}) che permette di indicare le priorità dei
+ pacchetti. Il campo TOS è di 8 bit e l'opzione richiede per \param{optval}
+ un intero che ne contiene il valore. Sono definite anche alcune costanti che
+ definiscono alcuni valori standardizzati per il \textit{Type of Service},
+ riportate in tab.~\ref{tab:IP_TOS_values}, il valore di default usato da
+ Linux è \const{IPTOS\_LOWDELAY}, ma esso può essere modificato con le
+ funzionalità del cosiddetto \textit{Advanced Routing}. Si ricordi che la
+ priorità dei pacchetti può essere impostata anche in maniera indipendente
+ dal protocollo utilizzando l'opzione \const{SO\_PRIORITY} illustrata in
+ sez.~\ref{sec:sock_generic_options}.
+
+
+\item[\const{IP\_TTL}] L'opzione consente di leggere o impostare il campo
+ \textit{Time to Live} dell'intestazione IP (vedi sez.~\ref{sec:IP_header}).
+ Il campo TTL è di 8 bit e l'opzione richiede che \param{optval} sia un
+ intero, che ne conterrà il valore.
+
+
+\item[\const{IP\_HDRINCL}] Se abilitata l'utente deve fornire lui stesso
+ l'intestazione IP in cima ai propri dati. L'opzione è valida soltanto per
+ socket di tipo \const{SOCK\_RAW}, e quando utilizzata eventuali valori
+ impostati con \const{IP\_OPTIONS}, \const{IP\_TOS} o \const{IP\_TTL} sono
+ ignorati. In ogni caso prima della spedizione alcuni campi
+ dell'instestazione vengono comunque modificati dal kernel, torneremo
+ sull'argomento in sez.~\ref{sec:socket_raw_xxx}
+
+
+\item[\const{IP\_RECVERR}] Questa è una opzione introdotta con i kernel della
+ serie 2.2.x, ed è specifica di Linux. Essa permette di usufruire di un
+ meccanismo affidabile per ottenere un maggior numero di informazioni in caso
+ di errori. Se l'opzione è abilitata tutti gli errori generati su un socket
+ vengono memorizzati su una coda, dalla quale poi possono essere letti con
+ \func{recvmsg} (torneremo su questo in sez.~\ref{sec:TCP_ancillary_data}).
+ L'opzione richiede per \param{optval} un intero usato come valore logico;
+ l'opzione non è applicabile a socket di tipo \const{SOCK\_STREAM}.
+
+\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
+ della serie 2.2.x, ed è specifica di Linux. L'opzione permette di scrivere
+ o leggere le impostazioni usante nella determinazione della \textit{Maximum
+ Tranfer Unit} (vedi sez.~\ref{sec:net_lim_dim}) per il socket.
+
+\item[\const{IP\_MTU}] Permette di leggere il valore della \textit{Maximum
+ Tranfer Unit} di percorso del socket. L'opzione richiede per
+ \param{optval} un intero che conterrà il valore della MTU in byte. Questa è
+ una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
+ Linux.
+
+\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i kernel
+ della serie 2.2.x, ed è specifica di Linux.
+
+\item[\const{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il
+ valore del campo TTL per i pacchetti in uscita associati al socket. È
+ importante che questo valore sia il più basso possibile, ed il default è 1,
+ che significa che i pacchetti non potranno uscire dalla rete locale. Questa
+ opzione consente ai programmi che lo richiedono di superare questo limite.
+ L'opzione richiede per \param{optval} un intero che conterrà il valore del
+ TTL.
+
+\item[\const{IP\_MULTICAST\_LOOP}] L'opzione consente di decidere se i dati
+ che si inviano su un socket usato con il multicast vengano ricevuti anche
+ sulla stessa macchina da cui li si stanno inviando. Prende per
+ \param{optval} un intero usato come valore logico.
+
+ In generale se si vuole che eventuali client possano ricevere i dati che si
+ inviano occorre che questa funzionalità sia abilitata (come avviene di
+ default). Qualora però non si voglia generare traffico per dati che già sono
+ disponibili in locale l'uso di questa opzione permette di disabilitare
+ questo tipo di traffico.
+
+\item[\const{IP\_ADD\_MEMBERSHIP}]
+
+\item[\const{IP\_DROP\_MEMBERSHIP}]
+
+\item[\const{IP\_MULTICAST\_IF}]
+
\end{basedescript}
+
\section{Altre funzioni di controllo}
\label{sec:sock_ctrl_func}
Come ultimo argomento di questa sezione tratteremo l'uso della funzione
\func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
-impostazioni relative a proprietà generali dei socket (di tutti quelli di un
-certo tipo o di tutti quelli che usano un certo protocollo) rispetto alle
-funzioni viste finora che consentono di controllare quelle di un singolo
-socket.
+impostazioni relative alle proprietà dei socket. La differenza nell'uso di
+\func{sysctl} rispetto alle funzioni viste finora è che esse consentono di
+controllare le proprietà di un singolo socket, mentre con \func{sysctl} si
+impostano proprietà (o valori di default) validi a livello dell'intero
+sistema.
+
+Le opzioni disponibili per le proprietà della rete sono riportate nella
+gerarchia dei valori impostabili con \func{sysctl}, sotto il nodo
+\texttt{net}, o, se acceduti tramite l'interfaccia del filesystem
+\texttt{/proc}, sotto \texttt{/proc/sys/net}. In genere sotto questa directory
+compaiono le sottodirectory (corrispondenti ad altrettanti sottonodi per
+\func{sysctl}) relative ai vari protocolli e tipi di interfacce su cui è
+possibile intervenire per effettuare impostazioni; un contenuto tipico di
+questa directory è il seguente:
+\begin{verbatim}
+/proc/sys/net/
+|-- core
+|-- ethernet
+|-- ipv4
+|-- ipv6
+|-- irda
+|-- token-ring
+`-- unix
+\end{verbatim}
+e sono presenti varie centinaia di diversi parametri; nel nostro caso ci
+limiteremo a vedere quelli più significativi.
+
+Nella directory \texttt{/proc/sys/net/core} sono disponibili i parametri
+generici validi per tutti i socket, quelli descritti anche nella rispettiva
+pagina di manuale.\footnote{quella accessibile con \texttt{man 7 socket}.}
+I principali sono:
+
+\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{rmem\_default}] imposta la dimensione di default del buffer di
+ lettura (cioè per i dati in ingresso) dei socket.
+\item[\texttt{rmem\_max}] imposta la dimensione massima che si può assegnare al
+ buffer di ingresso dei socket attraverso l'uso dell'opzione
+ \const{SO\_RCVBUF}.
+\item[\texttt{wmem\_default}] imposta la dimensione di default del buffer di
+ scrittura (cioè per i dati in uscita) dei socket.
+\item[\texttt{wmem\_max}] imposta la dimensione massima che si può assegnare al
+ buffer di uscita dei socket attraverso l'uso dell'opzione
+ \const{SO\_SNDBUF}.
+\item[\texttt{message\_cost}]
+\item[\texttt{message\_burst}]
+\item[\texttt{netdev\_max\_backlog}]
+\item[\texttt{optmem\_max}]
+\end{basedescript}
+Nella directory \texttt{/proc/sys/net/ipv4} sono disponibili i parametri per i
+socket IPv4, descritti anche nella rispettiva pagina di
+manuale.\footnote{quella accessibile con \texttt{man 7 ip}.} I principali
+sono:
+\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{ip\_no\_pmtu\_disc}] imposta la discliplina di ricerca della
+ \textit{Path MTU} (vedi sez.~\ref{sec:net_lim_dim} e
+ sez.~\ref{sec:sock_ipv4_options}).
+\end{basedescript}
projects / gapil.git / blobdiff