+\subsection{Le uso delle principali opzioni dei socket}
+\label{sec:sock_options_main}
+
+L'elenco sintetico delle caratteristiche delle opzioni dei socket riportato in
+sez.~\ref{sec:sock_generic_options} non è sufficientemente dettagliato per
+permetterci di approfondire il significato di alcune di esse, che assumono
+grande importanza nella programmazione dei socket. Per questo motivo
+tratteremo ulteriormente l'uso di alcune di esse in questa sezione.
+
+\index{\texttt{SO\_KEEPALIVE} (costante)|(}
+La prima opzione da approfondire è \const{SO\_KEEPALIVE}, che come accennato
+permette di controllare automaticamente lo stato di una connessione. Una
+connessione infatti può restare attiva anche se non viene effettuato alcun
+traffico su di essa, ma 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}.
+\index{\texttt{SO\_KEEPALIVE} (costante)|)}
+
+
+\index{\texttt{SO\_REUSEADDR} (costante)|(}
+La seconda opzione da approfondire è \const{SO\_REUSEADDR}. 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 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 per
+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 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 primo programma che ha eseguito \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)|(} 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} è quello di terminare immediatamente dopo
+la chiamata, mentre il procedimento di chiusura della connessione e l'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} permette di modificare (ed eventualmente
+ripristinare) questo comportamento in base ai valori passati nei campi della
+stuttura \struct{linger}. 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.
+
+Se però si utilizza un valore di \var{l\_onoff} diverso da zero per
+l'impostazione di \const{SO\_LINGER} il comportamento dipende dal valore di
+\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 viene inviato un segmento di RST che termina
+immediatamente la connessione. Se invece \var{l\_linger} ha un valore diverso
+da zero sia \func{close} che \func{shutdown} si bloccano e non ritornano
+fintanto che non si sia concluso il procedimento di chiusura della
+connessione, o non siano passati il numero di secondi specificati da
+\var{l\_linger}.
+\index{\texttt{SO\_LINGER} (costante)|)}
+
+
+
+
+