+\label{sec:sock_options}
+
+Benché dal punto di vista del loro uso come canali di trasmissione di dati i
+socket vengano trattati allo stesso modo dei file, acceduti tramite i file
+descriptor, e gestiti con le ordinarie funzioni di lettura e scrittura dei
+file, l'interfaccia standard usata per la gestione dei file generici non è
+comunque sufficiente a controllare la moltitudine di caratteristiche
+specifiche che li contraddistinguono, considerato tra l'altro che queste
+possono essere completamente diverse fra loro a seconda del tipo di socket e
+della relativa forma di comunicazione sottostante.
+
+In questa sezione vedremo allora quali sono le funzioni dedicate alla gestione
+delle caratteristiche specifiche dei vari tipi di socket, che vengono
+raggruppate sotto il nome generico di ``\textit{socket options}'', ma
+soprattutto analizzaremo quali sono queste opzioni e quali caretteristiche e
+comportamenti dei socket permettono di controllare.
+
+
+\subsection{Le funzioni di gestione delle opzioni dei socket}
+\label{sec:sock_setsockopt}
+
+La modalità principale con cui si possono gestire le caratteristiche dei
+socket (ne vedremo delle ulteriori nelle prossime sezioni) è quella che passa
+attraverso l'uso di due funzioni di sistema generiche che permettono
+rispettivamente di impostarle e di recuperarne il valore corrente. La prima di
+queste due funzioni, quella usata per impostare le \textit{socket options}, è
+\funcd{setsockopt}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fhead{sys/types.h}
+\fdecl{int setsockopt(int sock, int level, int optname, const void
+ *optval, socklen\_t optlen)}
+\fdesc{Imposta le opzioni di un socket.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
+ \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
+ \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
+ \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
+ indicato.
+ \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
+ un socket.
+ \end{errlist}
+}
+\end{funcproto}
+
+Il primo argomento della funzione, \param{sock}, indica il socket su cui si
+intende operare; per indicare l'opzione da impostare si devono usare i due
+argomenti successivi, \param{level} e \param{optname}. Come abbiamo visto in
+sez.~\ref{sec:net_protocols} i protocolli di rete sono strutturati su vari
+livelli, ed l'interfaccia dei socket può usarne più di uno. Si avranno allora
+funzionalità e caratteristiche diverse per ciascun protocollo usato da un
+socket, e quindi saranno anche diverse le opzioni che si potranno impostare
+per ciascun socket, a seconda del \textsl{livello} (trasporto, rete, ecc.) su
+cui si vuole andare ad operare.
+
+Il valore di \param{level} seleziona allora il protocollo su cui vuole
+intervenire, mentre \param{optname} permette di scegliere su quale delle
+opzioni che sono definite per quel protocollo si vuole operare. In sostanza la
+selezione di una specifica opzione viene fatta attraverso una coppia di valori
+\param{level} e \param{optname} e chiaramente la funzione avrà successo
+soltanto se il protocollo in questione prevede quella opzione ed è utilizzato
+dal socket. Infine \param{level} prevede anche il valore speciale
+\const{SOL\_SOCKET} usato per le opzioni generiche che sono disponibili per
+qualunque tipo di socket.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Livello} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{SOL\_SOCKET}& Opzioni generiche dei socket.\\
+ \constd{SOL\_IP} & Opzioni specifiche per i socket che usano IPv4.\\
+ \constd{SOL\_TCP} & Opzioni per i socket che usano TCP.\\
+ \constd{SOL\_IPV6} & Opzioni specifiche per i socket che usano IPv6.\\
+ \constd{SOL\_ICMPV6}& Opzioni specifiche per i socket che usano ICMPv6.\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori dell'argomento \param{level} delle
+ funzioni \func{setsockopt} e \func{getsockopt}.}
+ \label{tab:sock_option_levels}
+\end{table}
+
+I valori usati per \param{level}, corrispondenti ad un dato protocollo usato
+da un socket, sono quelli corrispondenti al valore numerico che identifica il
+suddetto protocollo in \conffile{/etc/protocols}; dato che la leggibilità di un
+programma non trarrebbe certo beneficio dall'uso diretto dei valori numerici,
+più comunemente si indica il protocollo tramite le apposite costanti
+\texttt{SOL\_*} riportate in tab.~\ref{tab:sock_option_levels}, dove si sono
+riassunti i valori che possono essere usati per l'argomento
+\param{level}.
+
+La notazione in questo caso è, purtroppo, abbastanza confusa: infatti in Linux
+il valore si può impostare sia usando le costanti \texttt{SOL\_*}, che le
+analoghe \texttt{IPPROTO\_*} (citate anche da Stevens in \cite{UNP1});
+entrambe hanno gli stessi valori che sono equivalenti ai numeri di protocollo
+di \conffile{/etc/protocols}, con una eccezione specifica, che è quella del
+protocollo ICMP, per la quale non esiste una costante, il che è comprensibile
+dato che il suo valore, 1, è quello che viene assegnato a \const{SOL\_SOCKET}.
+
+Il quarto argomento, \param{optval} è un puntatore ad una zona di memoria che
+contiene i dati che specificano il valore dell'opzione che si vuole passare al
+socket, mentre l'ultimo argomento \param{optlen},\footnote{questo argomento è
+ in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
+ \acr{libc5}; l'uso di \type{socklen\_t} è stato introdotto da POSIX (valgono
+ le stesse considerazioni per l'uso di questo tipo di dato fatte in
+ sez.~\ref{sec:TCP_func_accept}) ed adottato dalla \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
+variabili.
+
+La gran parte delle opzioni utilizzano per \param{optval} un valore intero, se
+poi l'opzione esprime una condizione logica, il valore è sempre un intero, ma
+si dovrà usare un valore non nullo per abilitarla ed un valore nullo per
+disabilitarla. Se invece l'opzione non prevede di dover ricevere nessun tipo
+di valore si deve impostare \param{optval} a \val{NULL}. Un piccolo numero
+di opzioni però usano dei tipi di dati peculiari, è questo il motivo per cui
+\param{optval} è stato definito come puntatore generico.
+
+La seconda funzione usata per controllare le proprietà dei socket è
+\funcd{getsockopt}, che serve a leggere i valori delle opzioni dei socket ed a
+farsi restituire i dati relativi al loro funzionamento; il suo prototipo è:
+
+
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fhead{sys/types.h}
+\fdecl{int getsockopt(int s, int level, int optname, void *optval,
+ socklen\_t *optlen)}
+\fdesc{Legge le opzioni di un socket.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
+ \item[\errcode{EFAULT}] l'indirizzo \param{optval} o quello di
+ \param{optlen} non è valido.
+ \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
+ indicato.
+ \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
+ un socket.
+ \end{errlist}
+}
+\end{funcproto}
+
+I primi tre argomenti sono identici ed hanno lo stesso significato di quelli
+di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
+per entrambe le funzioni. In questo caso \param{optval} viene usato per
+ricevere le informazioni ed indica l'indirizzo a cui andranno scritti i dati
+letti dal socket, infine \param{optlen} diventa un puntatore ad una variabile
+che viene usata come \textit{value result argument} per indicare, prima della
+chiamata della funzione, la lunghezza del buffer allocato per \param{optval} e
+per ricevere indietro, dopo la chiamata della funzione, la dimensione
+effettiva dei dati scritti su di esso. Se la dimensione del buffer allocato
+per \param{optval} non è sufficiente si avrà un errore.
+
+
+
+\subsection{Le opzioni generiche}
+\label{sec:sock_generic_options}
+
+Come accennato esiste un insieme generico di opzioni dei socket che possono
+applicarsi a qualunque tipo di socket, indipendentemente da quale protocollo
+venga poi utilizzato. Una descrizione di queste opzioni è generalmente
+disponibile nella settima sezione delle pagine di manuale; nel caso specifico
+la si può consultare con \texttt{man 7 socket}. Se si vuole operare su queste
+opzioni generiche il livello da utilizzare è \const{SOL\_SOCKET}; si è
+riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_socklevel}.
+
+
+\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{SO\_ACCEPTCONN}&$\bullet$& & &\texttt{int}&
+ Indica se il socket è in ascolto.\\
+ \const{SO\_ATTACH\_FILTER}& &$\bullet$& &\texttt{sock\_fprog}&
+ Aggancia un filtro BPF al socket.\\
+ \const{SO\_BINDTODEVICE}&$\bullet$&$\bullet$& &\texttt{char *}&
+ Lega il socket ad un dispositivo.\\
+ \const{SO\_BROADCAST}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Attiva o disattiva il \textit{broadcast}.\\
+ \const{SO\_BSDCOMPAT}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita la compatibilità con BSD.\\
+ \const{SO\_BUSY\_POLL}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Attiva il ``\textit{busy poll}'' sul socket.\\
+ \const{SO\_DEBUG} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita il debugging sul socket.\\
+ \const{SO\_DETACH\_FILTER}& &$\bullet$&$\bullet$&\texttt{int}&
+ Rimuove il filtro BPF agganciato al socket.\\
+ \const{SO\_DOMAIN} &$\bullet$& & &\texttt{int}&
+ Legge il tipo di socket.\\
+ \const{SO\_DONTROUTE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Non invia attraverso un gateway.\\
+ \const{SO\_ERROR} &$\bullet$& & &\texttt{int}&
+ Riceve e cancella gli errori pendenti.\\
+ \const{SO\_KEEPALIVE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Controlla l'attività della connessione.\\
+ \const{SO\_LINGER} &$\bullet$&$\bullet$& &\texttt{linger}&
+ Indugia nella chiusura con dati da spedire.\\
+ \const{SO\_LOCK\_FILTER}& &$\bullet$&$\bullet$&\texttt{int}&
+ Blocca il filtro BPF agganciato al socket.\\
+ \const{SO\_MARK} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta un ``\textit{firewall mark}'' sul socket.\\
+ \const{SO\_OOBINLINE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Lascia in linea i dati \textit{out-of-band}.\\
+ \const{SO\_PASSCRED} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita la ricezione di credenziali.\\
+ \const{SO\_PEEK\_OFF} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta il valore del ``\textit{peek offset}''.\\
+ \const{SO\_PEERCRED} &$\bullet$& & &\texttt{ucred}&
+ Restituisce le credenziali del processo remoto.\\
+ \const{SO\_PRIORITY} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta la priorità del socket.\\
+ \const{SO\_PROTOCOL} &$\bullet$& & &\texttt{int}&
+ Ottiene il protocollo usato dal socket.\\
+ \const{SO\_RCVBUF} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta dimensione del buffer di ricezione.\\
+ \const{SO\_RCVBUFFORCE}&$\bullet$&$\bullet$& &\texttt{int}&
+ Forza dimensione del buffer di ricezione.\\
+ \const{SO\_RCVLOWAT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Basso livello sul buffer di ricezione.\\
+ \const{SO\_RCVTIMEO} &$\bullet$&$\bullet$& &\texttt{timeval}&
+ Timeout in ricezione.\\
+ \const{SO\_REUSEADDR}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Consente il riutilizzo di un indirizzo locale.\\
+ \const{SO\_REUSEPORT}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Consente il riutilizzo di una porta.\\
+ \const{SO\_RXQ\_OVFL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Richiede messaggio ancillare con pacchetti persi.\\
+ \const{SO\_SNDBUF} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta dimensione del buffer di trasmissione.\\
+ \const{SO\_SNDBUFFORCE}&$\bullet$&$\bullet$& &\texttt{int}&
+ Forza dimensione del buffer di trasmissione.\\
+ \const{SO\_SNDLOWAT} &$\bullet$&$\bullet$& &\texttt{int}&
+ Basso livello sul buffer di trasmissione.\\
+ \const{SO\_SNDTIMEO} &$\bullet$&$\bullet$& &\texttt{timeval}&
+ Timeout in trasmissione.\\
+ \const{SO\_TIMESTAMP}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita/disabilita la ricezione dei \textit{timestamp}.\\
+ \const{SO\_TYPE} &$\bullet$& & &\texttt{int}&
+ Restituisce il tipo di socket.\\
+ \hline
+ \end{tabular}
+ \caption{Le opzioni disponibili al livello \const{SOL\_SOCKET}.}
+ \label{tab:sock_opt_socklevel}
+\end{table}
+
+% TODO aggiungere e documentare SO_ATTACH_BPF, introdotta con il kernel 3.19,
+% vedi http://lwn.net/Articles/625224/
+% TODO aggiungere e documentare SO_INCOMING_CPU, introdotta con il kernel 3.19,
+% TODO documentare SO_PEERGROUPS introdotta con il kernel 4.13, citata
+% in https://lwn.net/Articles/727385/
+% TODO documentare SO_ZEROCOPY, vedi https://lwn.net/Articles/726917/ (e il
+% resto pure) introdotta con il kernel 4.14
+
+La tabella elenca le costanti che identificano le singole opzioni da usare
+come valore per \param{optname}; le due colonne seguenti indicano per quali
+delle due funzioni (\func{getsockopt} o \func{setsockopt}) l'opzione è
+disponibile, mentre la colonna successiva indica, quando si ha a che fare con
+un valore di \param{optval} intero, se l'opzione è da considerare un numero o
+un valore logico. Si è inoltre riportato sulla quinta colonna il tipo di dato
+usato per \param{optval} ed una breve descrizione del significato delle
+singole opzioni sulla sesta.
+
+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.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{SO\_ACCEPTCONN}] questa opzione permette di rilevare se il socket
+ su cui opera è stato posto in modalità di ricezione di eventuali connessioni
+ con una chiamata a \func{listen}. L'opzione può essere usata soltanto con
+ \func{getsockopt} ed utilizza per \param{optval} un intero in cui viene
+ restituito 1 se il socket è in ascolto e 0 altrimenti.
+
+\item[\constd{SO\_ATTACH\_FILTER}] questa opzione permette di agganciare ad un
+ socket un filtro di selezione dei pacchetti con la stessa sintassi del BPF
+ (\textit{Berkley Packet Filter}) di BSD, che consente di selezionare, fra
+ tutti quelli ricevuti, verranno letti. Può essere usata solo con
+ \func{setsockopt} ed utilizza per \param{optval} un puntatore ad una
+ struttura \struct{sock\_fprog} (definita in
+ \headfile{linux/filter.h}). Questa opzione viene usata principalmente con i
+ socket di tipo \const{AF\_PACKET} (torneremo su questo in
+ sez.~\ref{sec:packet_socket}) dalla libreria \texttt{libpcap} per
+ implementare programmi di cattura dei pacchetti, e per questo tipo di
+ applicazione è opportuno usare sempre quest'ultima.\footnote{la trattazione
+ del BPF va al di là dell'argomento di questa sezione per la documentazione
+ si consulti il file \texttt{networking/filter.txt} nella documentazione
+ del kernel.}
+
+\item[\constd{SO\_BINDTODEVICE}] questa opzione permette di \textsl{legare} il
+ 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 \constd{IFNAMSIZ}; l'opzione è
+ effettiva solo per alcuni tipi di socket, ed in particolare per quelli della
+ famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
+ socket} (vedi sez.~\ref{sec:socket_raw}).
+
+\item[\constd{SO\_BROADCAST}] questa opzione abilita il \textit{broadcast}:
+ quando abilitata i socket di tipo \const{SOCK\_DGRAM} riceveranno i
+ pacchetti inviati all'indirizzo di \textit{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[\constd{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
+ comportamento di BSD (in particolare ne riproduce alcuni bug). Attualmente
+ è una opzione usata solo per il protocollo UDP e ne è prevista la rimozione.
+ L'opzione utilizza per \param{optval} un intero usato come valore logico.
+
+ Quando viene abilitata gli errori riportati da messaggi ICMP per un socket
+ UDP non vengono passati al programma in \textit{user space}. Con le versioni
+ 2.0.x del kernel erano anche abilitate altre opzioni di compatibilità per i
+ socket raw (modifiche casuali agli header, perdita del flag di
+ \textit{broadcast}) che sono state rimosse con il passaggio al 2.2; è
+ consigliato correggere i programmi piuttosto che usare questa funzione. Dal
+ kernel 2.4 viene ignorata, e dal 2.6 genera un messaggio di log del kernel.
+
+\item[\constd{SO\_BUSY\_POLL}] questa opzione, presente dal kernel 3.11,
+ imposta un tempo approssimato in microsecondi, per cui in caso di ricezione
+ bloccante verrà eseguito un \itindex{busy~poll} ``\textit{busy
+ poll}'',\footnote{con \textit{busy poll} si fa riferimento al
+ \textit{polling} su una risorsa occupata; si continuerà cioè a tentare di
+ leggere anche quando non ci sono dati senza portare il processo stato di
+ \textit{sleep}, in alcuni casi, quando ci si aspetta che i dati arrivino a
+ breve, questa tecnica può dare un miglioramento delle prestazioni.} da
+ indicare in \param{optval} con un valore intero. Si tratta di una opzione
+ utilizzabile solo con socket che ricevono dati da un dispositivo di rete che
+ la supporti, e che consente di ridurre la latenza per alcune applicazioni,
+ ma che comporta un maggiore utilizzo della CPU (e quindi di energia); per
+ questo il valore può essere aumentato solo da processi con i privilegi di
+ amministratore (in particolare con la \textit{capability}
+ \const{CAP\_NET\_ADMIN}). Il valore di default viene controllato dal file
+ \sysctlrelfile{net/core}{busy\_read} per le funzioni di lettura mentre il
+ file \sysctlrelfile{net/core}{busy\_poll} controlla il ``\textit{busy
+ poll}'' per \func{select} e \func{poll}.
+
+\item[\constd{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 \macrod{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
+ \macrod{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
+ solo sui socket TCP, causando la scrittura di tutti i pacchetti inviati
+ sulla rete su un buffer circolare che viene letto da un apposito
+ programma, \cmd{trpt}.}
+
+\item[\constd{SO\_DETACH\_FILTER}] consente di distaccare un filtro
+ precedentemente aggiunto ad un socket con l'opzione
+ \const{SO\_ATTACH\_FILTER}, in genere non viene usata direttamente in quanto
+ i filtri BPF vengono automaticamente rimossi alla chiusura del socket, il
+ suo utilizzo è pertanto limitato ai rari casi in cui si vuole rimuovere un
+ precedente filtro per inserirne uno diverso. Come \const{SO\_ATTACH\_FILTER}
+ può essere usato solo \func{setsockopt} e prende per \param{optval} un
+ intero usato come valore logico.
+
+\item[\constd{SO\_DOMAIN}] questa opzione, presente dal kernel 2.6.32, legge
+ il ``\textsl{dominio}'' (la famiglia di indirizzi) del socket.
+. Funziona solo con \func{getsockopt}, ed
+ utilizza per \param{optval} un intero in cui verrà restituito il valore
+ numerico che lo identifica (ad esempio \texttt{AF\_INET}).
+
+\item[\constd{SO\_DONTROUTE}] questa opzione richiede che l'invio dei
+ pacchetti del socket sia eseguito soltanto verso una destinazione
+ direttamente connessa, impedendo l'uso di un \textit{gateway} e saltando
+ ogni processo relativo all'uso della tabella di routing del kernel. Prende
+ per \param{optval} un intero usato come valore logico. È equivalente all'uso
+ del flag \const{MSG\_DONTROUTE} su una \func{send} (vedi
+ sez.~\ref{sec:net_send_recv}).
+
+\item[\constd{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, nel quale viene restituito il codice di
+ errore, e la condizione di errore sul socket viene cancellata. Viene
+ usualmente utilizzata per ricevere il codice di errore, come accennato in
+ sez.~\ref{sec:TCP_sock_select}, quando si sta osservando il socket con una
+ \func{select} che ritorna a causa dello stesso.
+
+\item[\const{SO\_KEEPALIVE}] questa opzione abilita un meccanismo di verifica
+ della persistenza di una connessione associata al socket; è 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\_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 \headfile{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[\constd{SO\_LOCK\_FILTER}] consente di bloccare un filtro
+ precedentemente aggiunto ad un socket con l'opzione
+ \const{SO\_ATTACH\_FILTER}, in modo che non possa essere né rimosso né
+ modificato, questo consente di impostare un filtro su un socket, bloccarlo e
+ poi cedere i privilegi con la sicurezza che il filtro permarrà fino alla
+ chiusura del socket. Come \const{SO\_ATTACH\_FILTER} può essere usato solo
+ \func{setsockopt} e prende per \param{optval} un intero usato come valore
+ logico.
+
+\item[\constd{SO\_MARK}] questa opzione, presente dal kernel 2.6.25, imposta
+ un valore di marcatura sui pacchetti del socket. Questa è una funzionalità
+ specifica di Linux, ottenibile anche con l'uso del target \texttt{MARK}
+ del comando \texttt{iptables} (l'argomento è trattato in sez.~3.3.5 di
+ \cite{SGL}). Il valore di marcatura viene mantenuto all'interno dello stack
+ di rete del kernel e può essere usato sia dal \itindex{netfilter}
+ \textit{netfilter}\footnote{il \textit{netfilter} è l'infrastruttura usata
+ per il filtraggio dei pacchetti del kernel, per maggiori dettagli si
+ consulti il cap.~2 di \cite{FwGL}.} di Linux che per impostare politiche
+ di routing avanzato. Il valore deve essere specificato in \param{optval}
+ come un intero. L'opzione richiede i privilegi di amministratore con la
+ \textit{capability} \const{CAP\_NET\_ADMIN}.
+
+\item[\constd{SO\_OOBINLINE}] se questa opzione viene abilitata i dati
+ \textit{out-of-band} vengono inviati direttamente nel flusso di dati del
+ socket (e sono quindi letti con una normale \func{read}) invece che restare
+ disponibili solo per l'accesso con l'uso del flag \const{MSG\_OOB} di
+ \func{recvmsg}. L'argomento è trattato in dettaglio in
+ sez.~\ref{sec:TCP_urgent_data}. L'opzione funziona soltanto con socket che
+ 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[\constd{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[\constd{SO\_PEEK\_OFF}] questa opzione, disponibile a partire dal kernel
+ 3.4, imposta un ``\textit{peek offset}'' sul socket (attualmente disponibile
+ solo per i socket unix-domain (vedi sez.~\ref{sec:unix_socket}). La funzione
+ serve come ausilio per l'uso del flag \const{MSG\_PEEK} di \func{recv} che
+ consente di ``\textsl{sbirciare}'' nei dati di un socket, cioè di leggerli
+ senza rimuoverli dalla coda in cui sono mantenuti, così che vengano
+ restituiti anche da una successiva lettura ordinaria.
+
+ Un valore negativo (il default è $-1$) riporta alla situazione ordinaria in
+ cui si ``\textsl{sbircia}'' a partire dalla testa della coda, un valore
+ positivo consente di leggere a partire dalla posizione indicata nella coda e
+ tutte le volte che si sbirciano dei dati il valore dell'offset viene
+ automaticamente aumentato della quantità di dati sbirciati, in modo che si
+ possa proseguire da dove si era arrivati. Il valore deve essere specificato
+ in \param{optval} come intero.
+
+\item[\constd{SO\_PEERCRED}] questa opzione restituisce le credenziali del
+ processo remoto connesso al socket; l'opzione è disponibile solo per socket
+ unix-domain di tipo \textit{stream} e anche per quelli di tipo
+ \textit{datagram} quando se ne crea una coppia con \func{socketpair}, e può
+ essere usata solo con \func{getsockopt}. Utilizza per
+ \param{optval} una apposita struttura \struct{ucred} (vedi
+ sez.~\ref{sec:unix_socket}).
+
+\item[\constd{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 \textit{capability}
+ \const{CAP\_NET\_ADMIN}.
+
+\item[\constd{SO\_PROTOCOL}] questa opzione, presente dal kernel 2.6.32, legge
+ il protocollo usato dal socket. Funziona solo con \func{getsockopt}, ed
+ utilizza per \param{optval} un intero in cui verrà restituito il valore
+ numerico che lo identifica (ad esempio \texttt{IPPROTO\_TCP}).
+
+\item[\constd{SO\_RCVBUF}] questa opzione imposta la dimensione del buffer di
+ ricezione 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}).
+
+ Si tenga presente che nel caso di socket TCP il kernel alloca effettivamente
+ una quantità di memoria doppia rispetto a quanto richiesto con
+ \func{setsockopt} per entrambe le opzioni \const{SO\_RCVBUF} e
+ \const{SO\_SNDBUF}. Questo comporta che una successiva lettura con
+ \func{getsockopt} riporterà un valore diverso da quello impostato con
+ \func{setsockopt}. Questo avviene perché TCP necessita dello spazio in più
+ per mantenere dati amministrativi e strutture interne, e solo una parte
+ viene usata come buffer per i dati, mentre il valore letto da
+ \func{getsockopt} e quello riportato nei vari parametri di
+ \textit{sysctl}\footnote{cioè \sysctlrelfile{net/core}{wmem\_max} e
+ \sysctlrelfile{net/core}{rmem\_max} in \texttt{/proc/sys/net/core} e
+ \sysctlrelfile{net/ipv4}{tcp\_wmem} e \sysctlrelfile{net/ipv4}{tcp\_rmem}
+ in \texttt{/proc/sys/net/ipv4}, vedi sez.~\ref{sec:sock_sysctl}.} indica
+ la memoria effettivamente impiegata. Si tenga presente inoltre che le
+ modifiche alle dimensioni dei buffer di ricezione e trasmissione, per poter
+ essere effettive, devono essere impostate prima della chiamata alle funzioni
+ \func{listen} o \func{connect}.
+
+\item[\constd{SO\_RCVBUFFORCE}] questa opzione, presente dal kernel 2.6.14, è
+ identica a \const{SO\_RCVBUF} ma consente ad un processo con i privilegi di
+ amministratore (per la precisione con la \textit{capability}
+ \const{CAP\_NET\_ADMIN}) di impostare in valore maggiore del limite di
+ \sysctlrelfile{net/core}{rmem\_max}.
+
+\item[\constd{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
+ segnalando ad una \func{select} (vedi sez.~\ref{sec:TCP_sock_select}) che ci
+ sono dati in ingresso. L'opzione utilizza per \param{optval} un intero che
+ specifica il numero di byte; con Linux questo valore è sempre 1 e può essere
+ cambiato solo con i kernel a partire dal 2.4. Si tenga presente però che per
+ i kernel prima del 2.6.28 sia \func{poll} che \func{select} non supportano
+ questa funzionalità e ritornano comunque, indicando il socket come
+ leggibile, non appena almeno un byte è presente, con una successiva lettura
+ con \func{read} che si blocca fintanto che non diventa disponibile la
+ quantità di byte indicati. Con \func{getsockopt} si può leggere questo
+ valore mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}
+ quando il cambiamento non è supportato.
+
+\item[\constd{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})
+ identica a quella usata con \func{select}. Con \func{getsockopt} si può
+ leggere il valore attuale, mentre con \func{setsockopt} si imposta il tempo
+ voluto, usando un valore nullo per \struct{timeval} il timeout viene
+ rimosso.
+
+ Se l'opzione viene attivata tutte le volte che una delle funzioni di lettura
+ (\func{read}, \func{readv}, \func{recv}, \func{recvfrom} e \func{recvmsg})
+ si blocca in attesa di dati per un tempo maggiore di quello impostato, essa
+ ritornerà un valore -1 e la variabile \var{errno} sarà impostata con un
+ errore di \errcode{EAGAIN} e \errcode{EWOULDBLOCK}, così come sarebbe
+ avvenuto se si fosse aperto il socket in modalità non bloccante.\footnote{in
+ teoria, se il numero di byte presenti nel buffer di ricezione fosse
+ inferiore a quello specificato da \const{SO\_RCVLOWAT}, l'effetto potrebbe
+ essere semplicemente quello di provocare l'uscita delle funzioni di
+ lettura restituendo il numero di byte fino ad allora ricevuti.}
+
+ In genere questa opzione non è molto utilizzata se si ha a che fare con la
+ lettura dei dati, in quanto è sempre possibile usare una \func{select} che
+ consente di specificare un \textit{timeout}; l'uso di \func{select} non
+ consente però di impostare il timeout per l'uso di \func{connect}, per avere
+ il quale si può ricorrere a questa opzione (nel qual caso il raggiungimento
+ del \textit{timeout} restituisce l'errore \errcode{EINPROGRESS}).
+
+\item[\const{SO\_REUSEADDR}] questa opzione permette di eseguire la funzione
+ \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 (più propriamente il
+ controllo viene eseguito sulla porta) è già in uso da parte di un altro
+ socket. Maggiori dettagli sul suo funzionamento sono forniti in
+ sez.~\ref{sec:sock_options_main}.
+
+\item[\const{SO\_REUSEPORT}] questa opzione, presente a partire dal kernel
+ 3.9, permette di far usare a più socket di tipo \const{AF\_INET} o
+ \const{AF\_INET6} lo stesso indirizzo locale, e costituisce una estensione
+ della precedente \const{SO\_REUSEADDR}. Maggiori dettagli sul suo
+ funzionamento sono forniti in sez.~\ref{sec:sock_options_main}.
+
+\item[\constd{SO\_RXQ\_OVFL}] questa opzione, presente dal kernel 2.6.33,
+ permette di abilitare o disabilitare sul socket la ricezione di un messaggio
+ ancillare (tratteremo l'argomento in sez.~\ref{sec:net_ancillary_data})
+ contenente un intero senza segno a 32 bit che indica il numero di pacchetti
+ scartati sul socket fra l'ultimo pacchetto ricevuto e questo. L'opzione
+ utilizza per \param{optval} un intero usato come valore logico.
+
+% TODO documentare SO_RXQ_OVFL, vedi https://lwn.net/Articles/626150/ capire
+% che significa 'questo'
+
+\item[\constd{SO\_SNDLOWAT}] questa opzione imposta il valore che indica il
+ numero minimo di byte che devono essere presenti nel buffer di trasmissione
+ perché il kernel li invii al protocollo successivo, consentendo ad una
+ \func{write} di ritornare o segnalando ad una \func{select} (vedi
+ sez.~\ref{sec:TCP_sock_select}) che è possibile eseguire una scrittura.
+ L'opzione utilizza per \param{optval} un intero che specifica il numero di
+ byte; con Linux questo valore è sempre 1 e non può essere cambiato;
+ \func{getsockopt} leggerà questo valore mentre \func{setsockopt} darà un
+ errore di \errcode{ENOPROTOOPT}.
+
+\item[\constd{SO\_SNDBUF}] questa opzione imposta la dimensione del buffer di
+ trasmissione del socket. Prende per \param{optval} un intero indicante il
+ numero di byte. Il valore di default ed il valore massimo che si possono
+ specificare come argomento per questa opzione sono impostabili
+ rispettivamente tramite gli opportuni valori di \func{sysctl} (vedi
+ sez.~\ref{sec:sock_sysctl}).
+
+\item[\constd{SO\_SNDBUFFORCE}] questa opzione, presente dal kernel 2.6.14, è
+ identica a \const{SO\_SNDBUF} ma consente ad un processo con i privilegi di
+ amministratore (per la precisione con la \textit{capability}
+ \const{CAP\_NET\_ADMIN}) di impostare in valore maggiore del limite di
+ \sysctlrelfile{net/core}{wmem\_max}.
+
+% TODO verificare il timeout con un programma di test
+
+\item[\constd{SO\_SNDTIMEO}] l'opzione permette di impostare un tempo massimo
+ 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{sendto} e \func{sendmsg}
+ qualora queste restino bloccate per un tempo maggiore di quello specificato.
+
+\item[\constd{SO\_TIMESTAMP}] questa opzione, presente dal kernel 2.6.30,
+ permette di abilitare o disabilitare sul socket la ricezione di un messaggio
+ ancillare di tipo \const{SO\_TIMESTAMP}. Il messaggio viene inviato con
+ livello \const{SOL\_SOCKET} ed nel campo \var{cmsg\_data} (per i dettagli si
+ veda sez.~\ref{sec:net_ancillary_data}) viene impostata una struttura
+ \struct{timeval} che indica il tempo di ricezione dell'ultimo pacchetto
+ passato all'utente. L'opzione utilizza per \param{optval} un intero usato
+ come valore logico.
+
+% TODO capire meglio la tempistica di questi messaggi ancillari
+% TODO documentare SO_TIMESTAMP e le altre opzioni di timestamping dei
+% pacchetti, introdotte nel 2.6.30, vedi nei sorgenti del kernel:
+% Documentation/networking/timestamping.txt
+
+\item[\constd{SO\_TYPE}] questa opzione permette di leggere il tipo di socket
+ su cui si opera; funziona solo con \func{getsockopt}, ed utilizza per
+ \param{optval} un intero in cui verrà restituito il valore numerico che lo
+ identifica (ad esempio \const{SOCK\_STREAM}).
+
+
+\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 sintetica, 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.
+
+
+\constbeg{SO\_KEEPALIVE}
+\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; è
+allora possibile, in caso di una interruzione completa della rete, che la
+caduta della connessione non venga rilevata, dato che sulla stessa non passa
+comunque alcun traffico.
+
+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 i socket che supportano
+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} (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.
+
+Qualora ci siano dei problemi di rete si possono invece verificare i due casi
+di terminazione precoce del server già illustrati in
+sez.~\ref{sec:TCP_conn_crash}. Il primo è quello in cui la macchina remota ha
+avuto un crollo del sistema ed è stata riavviata, per cui dopo il riavvio la
+connessione non esiste più.\footnote{si ricordi che un normale riavvio o il
+ crollo dell'applicazione non ha questo effetto, in quanto in tal caso si
+ passa sempre per la chiusura del processo, e questo, come illustrato in
+ sez.~\ref{sec:file_open_close}, comporta anche la regolare chiusura del
+ socket con l'invio di un segmento FIN all'altro capo della connessione.} 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 ed il socket verrà chiuso riportando un errore
+di \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 modificati a livello di sistema (cioè per tutti i socket) con gli
+ opportuni parametri illustrati in sez.~\ref{sec:sock_sysctl} ed a livello di
+ singolo socket con le opzioni \texttt{TCP\_KEEP*} di
+ sez.~\ref{sec:sock_tcp_udp_options}.} (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 si riceve come
+risposta un pacchetto ICMP di destinazione irraggiungibile (vedi
+sez.~\ref{sec:ICMP_protocol}), 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
+verrebbero 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 o perché
+il client sull'altro capo non è più attivo o perché non è più in grado di
+comunicare con il server via rete.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \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
+verranno comunque chiuse per cui, utilizzando ad esempio una \func{select}, se
+ne 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 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.
+\constend{SO\_KEEPALIVE}
+
+
+
+\constbeg{SO\_REUSEADDR}
+\subsubsection{Le opzioni \const{SO\_REUSEADDR} e \const{SO\_REUSEPORT}}
+
+La seconda opzione da approfondire è \constd{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 in cui si fa ricorso a \const{SO\_REUSEADDR}, che è anche il più
+comune, è 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 relative 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}).
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/sockbindopt.c}
+ \end{minipage}
+ \normalsize
+ \caption{Le sezioni della funzione \texttt{sockbindopt} modificate rispetto al
+ codice della precedente \texttt{sockbind}.}
+ \label{fig:sockbindopt_code}
+\end{figure}
+
+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 \texttt{sockbind} (vedi fig.~\ref{fig:sockbind_code})
+che consenta l'impostazione di questa opzione. La nuova funzione è
+\texttt{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.
+
+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}.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \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 \texttt{sockbindopt}.}
+ \label{fig:TCP_echod_fifth}
+\end{figure}
+
+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}.
+
+Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
+macchina cui sono assegnati diversi indirizzi 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. Si tenga presente infatti che con il
+protocollo TCP non è in genere possibile far partire più server che eseguano
+\func{bind} sullo stesso indirizzo e la stessa porta se su di esso c'è già un
+socket in ascolto, cioè ottenere quello che viene chiamato un
+\itindex{completely~duplicate~binding} \textit{completely duplicate binding}
+(per questo è stata introdotta \const{SO\_REUSEPORT}).
+
+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 \constd{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. Come accennato questo con TCP non è possibile, ed ha anche
+poco senso pensare di mettere in ascolto due server sulla stessa porta. Se
+però si prende in considerazione il traffico in \textit{multicast}, diventa
+assolutamente normale che i pacchetti provenienti dal traffico in
+\textit{multicast} possano essere ricevuti da più applicazioni o da diverse
+istanze della stessa applicazione sulla stessa porte di un indirizzo di
+\textit{multicast}.
+
+Un esempio classico è quello di uno streaming di dati (audio, video, ecc.) in
+cui l'uso del \textit{multicast} consente di trasmettere un solo pacchetto da
+recapitare a 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, e quindi effettuare un \textit{completely duplicate
+ binding}.
+
+In questo caso utilizzando \const{SO\_REUSEADDR} si può consentire ad una
+applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
+un'altra, così che anche essa possa ricevere gli stessi pacchetti. Come detto
+la cosa non è possibile con i socket TCP (per i quali il \textit{multicast}
+comunque non è applicabile), ma lo è per quelli UDP che è il protocollo
+normalmente in uso da parte di queste applicazioni. La regola è che quando si
+hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
+tutti pacchetti destinati ad un indirizzo di \textit{broadcast} o di
+\textit{multicast} viene inviata una copia a ciascuna applicazione. Non è
+definito invece cosa accade qualora il pacchetto sia destinato ad un indirizzo
+normale (\textit{unicast}).
+
+% TODO documentare SO_REUSEPORT, vedi https://lwn.net/Articles/542260/
+
+\constbeg{SO\_REUSEPORT}
+
+Esistono però dei casi, in particolare per l'uso di programmi
+\textit{multithreaded}, in cui può servire un \textit{completely duplicate
+ binding} anche per delle ordinarie connessioni TCP. Per supportare queste
+esigenze a partire dal kernel 3.9 è stata introdotta un'altra opzione,
+\const{SO\_REUSEPORT} (già presente in altri sistemi come BSD), che consente
+di eseguire il \textit{completely duplicate binding}, fintanto che essa venga
+specificata per tutti i socket interessati. Come per \const{SO\_REUSEADDR}
+sarà possibile usare l'opzione su un socket legato allo stesso indirizzo e
+porta solo se il programma che ha eseguito il primo \func{bind} ha impostato
+questa opzione.
+
+Nel caso di \const{SO\_REUSEPORT} oltre al fatto che l'opzione deve essere
+attivata sul socket prima di chiamare \func{bind} ed attiva su tutti i socket
+con \textit{completely duplicate binding}, è richiesto pure che tutti i
+processi che si mettono in ascolto sullo stesso indirizzo e porta abbiano lo
+stesso \ids{UID} effettivo, per evitare che un altro utente possa ottenere il
+relativo traffico (eseguendo quello che viene definito \textit{port hijacking}
+o \textit{port stealing}). L'opzione utilizza per \param{optval} un intero
+usato come valore logico.
+
+L'opzione si usa sia per socket TCP che UDP, nel primo caso consente un uso
+distribuito di \func{accept} in una applicazione \textit{multithreaded}
+passando un diverso \textit{listening socket} ad ogni thread, cosa che
+migliora le prestazioni rispetto all'approccio tradizionale di usare un thread
+per usare \func{accept} e distribuire le connessioni agli altri o avere più
+thread che competono per usare \func{accept} sul socket. Nel caso di UDP
+l'opzione consente di distribuire meglio i pacchetti su più processi o thread,
+rispetto all'approccio tradizionale di far competere gli stessi per l'accesso
+in ricezione al socket.
+
+% TODO documentare SO_REUSEPORT introdotta con il kernel 3.9, vedi
+% http://git.kernel.org/linus/c617f398edd4db2b8567a28e899a88f8f574798d TODO:
+% in cosa differisce da REUSEADDR?
+
+\constend{SO\_REUSEPORT}
+\constend{SO\_REUSEADDR}
+
+
+\constbeg{SO\_LINGER}
+\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]{0.80\textwidth}
+ \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 struttura \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}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \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 semplicemente 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
+connessione. 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, stampandone
+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}.
+
+\constend{SO\_LINGER}
+
+
+
+\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; 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}.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|c|c|c|l|p{4.8cm}|}
+ \hline
+ \textbf{Opzione}&\texttt{get}&\texttt{set}&\textbf{flag}&\textbf{Tipo}&
+ \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{IP\_ADD\_MEMBERSHIP} & &$\bullet$& &\struct{ip\_mreqn}&
+ Si unisce a un gruppo di \textit{multicast}.\\
+ \const{IP\_ADD\_SOURCE\_MEMBERSHIP} & &$\bullet$& &\struct{ip\_mreq\_source}&
+ Si unisce a un gruppo di \textit{multicast} per una sorgente.\\
+ \const{IP\_BLOCK\_SOURCE} & &$\bullet$& &\struct{ip\_mreq\_source}&
+ Smette di ricevere dati di \textit{multicast} per una sorgente.\\
+ \const{IP\_DROP\_MEMBERSHIP}& &$\bullet$& &\struct{ip\_mreqn}&
+ Si sgancia da un gruppo di \textit{multicast}.\\
+ \const{IP\_DROP\_SOURCE\_MEMBERSHIP}& &$\bullet$& &\struct{ip\_mreq\_source}&
+ Si sgancia da un gruppo di \textit{multicast} per una sorgente.\\
+ \const{IP\_FREEBIND} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita il \textit{binding} a un indirizzo IP non locale ancora non assegnato.\\
+ \const{IP\_HDRINCL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa l'intestazione di IP nei dati.\\
+ \const{IP\_MINTTL} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta il valore minimo del TTL per i pacchetti accettati.\\
+ \const{IP\_MSFILTER} &$\bullet$&$\bullet$& &\struct{ip\_msfilter}&
+ Accesso completo all'interfaccia per il filtraggio delle sorgenti
+ \textit{multicast}.\\
+ \const{IP\_MTU} &$\bullet$& & &\texttt{int}&
+ Legge il valore attuale della MTU.\\
+ \const{IP\_MTU\_DISCOVER} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta il \textit{Path MTU Discovery}.\\
+ \const{IP\_MULTICAST\_ALL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta l'interfaccia locale di un socket \textit{multicast}.\\
+ \const{IP\_MULTICAST\_IF} & &$\bullet$& &\struct{ip\_mreqn}&
+ Imposta l'interfaccia locale di un socket \textit{multicast}.\\
+ \const{IP\_MULTICAST\_LOOP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Controlla il reinvio a se stessi dei dati di \textit{multicast}.\\
+ \const{IP\_MULTICAST\_TTL} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta il TTL per i pacchetti \textit{multicast}.\\
+ \const{IP\_NODEFRAG} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Disabilita il riassemblaggio di pacchetti frammentati.\\
+ \const{IP\_OPTIONS} &$\bullet$&$\bullet$&&\texttt{void *}& %???
+ Imposta o riceve le opzioni di IP.\\
+ \const{IP\_PKTINFO} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita i messaggi di informazione.\\
+ \const{IP\_RECVERR} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita i messaggi di errore affidabili.\\
+ \const{IP\_RECVOPTS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio con le opzioni IP.\\
+ \const{IP\_RECVORIGSTADDR} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita i messaggi con l'indirizzo di destinazione originale.\\
+ \const{IP\_RECVTOS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Passa un messaggio col campo TOS.\\
+ \const{IP\_RECVTTL} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita i messaggi col campo TTL.\\
+ \const{IP\_RETOPTS} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita i messaggi con le opzioni IP non trattate.\\
+ \const{IP\_ROUTER\_ALERT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Imposta l'opzione \textit{IP router alert} sui pacchetti.\\
+ \const{IP\_TOS} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta il valore del campo TOS.\\
+ \const{IP\_TRANSPARENT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita un \textit{proxing} trasparente sul socket.\\
+ \const{IP\_TTL} &$\bullet$&$\bullet$& &\texttt{int}&
+ Imposta il valore del campo TTL.\\
+ \const{IP\_UNBLOCK\_SOURCE} & &$\bullet$& &\struct{ip\_mreq\_source}&
+ Ricomincia a ricevere dati di \textit{multicast} per una sorgente.\\
+ \hline
+ \end{tabular}
+ \caption{Le opzioni disponibili al livello \const{IPPROTO\_IP}.}
+ \label{tab:sock_opt_iplevel}
+\end{table}
+
+Se si vuole operare su queste opzioni generiche il livello da utilizzare è
+\constd{IPPROTO\_IP} (o l'equivalente \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 \headfiled{netinet/ip.h}, ed accessibili includendo detto file.
+
+Le descrizioni riportate in tab.~\ref{tab:sock_opt_iplevel} sono estremamente
+succinte, una maggiore quantità di dettagli sulle varie opzioni è fornita nel
+seguente elenco:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{IP\_ADD\_MEMBERSHIP}] L'opzione consente di unirsi ad gruppo di
+ \textit{multicast}, e può essere usata solo con \func{setsockopt}.
+ L'argomento \param{optval} in questo caso deve essere una struttura di tipo
+ \struct{ip\_mreqn}, illustrata in fig.~\ref{fig:ip_mreqn_struct}, che
+ permette di indicare, con il campo \var{imr\_multiaddr} l'indirizzo del
+ gruppo di \textit{multicast} a cui ci si vuole unire, con il campo
+ \var{imr\_address} l'indirizzo dell'interfaccia locale con cui unirsi al
+ gruppo di \textit{multicast} e con \var{imr\_ifindex} l'indice
+ dell'interfaccia da utilizzare (un valore nullo indica una interfaccia
+ qualunque).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.90\textwidth}
+ \includestruct{listati/ip_mreqn.h}
+ \end{minipage}
+ \caption{La struttura \structd{ip\_mreqn} utilizzata per unirsi a un gruppo di
+ \textit{multicast}.}
+ \label{fig:ip_mreqn_struct}
+\end{figure}
+
+Questa struttura è presente a partire dal kernel 2.2, per compatibilità è
+possibile utilizzare anche un argomento di tipo \struct{ip\_mreq}, presente
+fino dal kernel 1.2, che differisce da essa soltanto per l'assenza del campo
+\var{imr\_ifindex}; il kernel riconosce il tipo di struttura in base alla
+differente dimensione passata in \param{optlen}.
+
+\item[\constd{IP\_ADD\_SOURCE\_MEMBERSHIP}] L'opzione consente di unirsi ad
+ gruppo di \textit{multicast}, ricevendo i dati solo da una sorgente
+ specifica; come \const{IP\_ADD\_MEMBERSHIP} può essere usata solo con
+ \func{setsockopt}.