+\item[\const{IP\_DROP\_MEMBERSHIP}] Lascia un gruppo di \textit{multicast},
+ prende per \param{optval} la stessa struttura \struct{ip\_mreqn} (o
+ \struct{ip\_mreq}) usata anche per \const{IP\_ADD\_MEMBERSHIP}.
+
+\item[\const{IP\_MULTICAST\_IF}] Imposta l'interfaccia locale per l'utilizzo
+ del \textit{multicast}, ed utilizza come \param{optval} le stesse strutture
+ \struct{ip\_mreqn} o \struct{ip\_mreq} delle due precedenti opzioni.
+
+\itindend{multicast}
+\end{basedescript}
+
+
+
+\subsection{Le opzioni per i protocolli TCP e UDP}
+\label{sec:sock_tcp_udp_options}
+
+In questa sezione tratteremo le varie opzioni disponibili per i socket che
+usano i due principali protocolli di comunicazione del livello di trasporto;
+UDP e TCP.\footnote{come per le precedenti, una descrizione di queste opzioni
+ è disponibile nella settima sezione delle pagine di manuale, che si può
+ consultare rispettivamente con \texttt{man 7 tcp} e \texttt{man 7 udp}; le
+ pagine di manuale però, alla stesura di questa sezione (Agosto 2006) sono
+ alquanto incomplete.} Dato che questi due protocolli sono entrambi
+trasportati su IP,\footnote{qui si sottintende IPv4, ma le opzioni per TCP e
+ UDP sono le stesse anche quando si usa IPv6.} oltre alle opzioni generiche
+di sez.~\ref{sec:sock_generic_options} saranno comunque disponibili anche le
+precedenti opzioni di sez.~\ref{sec:sock_ipv4_options}.\footnote{in realtà in
+ sez.~\ref{sec:sock_ipv4_options} si sono riportate le opzioni per IPv4, al
+ solito, qualora si stesse utilizzando IPv6, si potrebbero utilizzare le
+ opzioni di quest'ultimo.}
+
+Il protocollo che supporta il maggior numero di opzioni è TCP; per poterle
+utilizzare occorre specificare \const{SOL\_TCP} (o l'equivalente
+\const{IPPROTO\_TCP}) come valore per l'argomento \param{level}. Si sono
+riportate le varie opzioni disponibili in tab.~\ref{tab:sock_opt_tcplevel},
+dove sono elencate le rispettive costanti da utilizzare come valore per
+l'argomento \param{optname}. Dette costanti e tutte le altre costanti e
+strutture collegate all'uso delle opzioni TCP sono definite in
+\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
+ questo è il file usato dalle librerie; la definizione delle opzioni
+ effettivamente supportate da Linux si trova nel file \texttt{linux/tcp.h},
+ dal quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
+
+\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{TCP\_NODELAY} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Spedisce immediatamente i dati in segmenti singoli.\\
+ \const{TCP\_MAXSEG} &$\bullet$&$\bullet$& &\texttt{int}&
+ Valore della \itindex{Maximum~Segment~Size} MSS per i segmenti in
+ uscita.\\
+ \const{TCP\_CORK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Accumula i dati in un unico segmento.\\
+ \const{TCP\_KEEPIDLE} &$\bullet$&$\bullet$& &\texttt{int}&
+ Tempo in secondi prima di inviare un \textit{keepalive}.\\
+ \const{TCP\_KEEPINTVL} &$\bullet$&$\bullet$& &\texttt{int}&
+ Tempo in secondi prima fra \textit{keepalive} successivi.\\
+ \const{TCP\_KEEPCNT} &$\bullet$&$\bullet$& &\texttt{int}&
+ Numero massimo di \textit{keepalive} inviati.\\
+ \const{TCP\_SYNCNT} &$\bullet$&$\bullet$& &\texttt{int}&
+ Numero massimo di ritrasmissioni di un SYN.\\
+ \const{TCP\_LINGER2} &$\bullet$&$\bullet$& &\texttt{int}&
+ Tempo di vita in stato \texttt{FIN\_WAIT2}.\\
+ \const{TCP\_DEFER\_ACCEPT}&$\bullet$&$\bullet$& &\texttt{int}&
+ Ritorna da \func{accept} solo in presenza di dati.\\
+ \const{TCP\_WINDOW\_CLAMP}&$\bullet$&$\bullet$& &\texttt{int}&
+ Valore della \itindex{advertised~window} \textit{advertised window}.\\
+ \const{TCP\_INFO} &$\bullet$& & &\struct{tcp\_info}&
+ Restituisce informazioni sul socket.\\
+ \const{TCP\_QUICKACK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
+ Abilita la modalità \textit{quickack}.\\
+ \const{TCP\_CONGESTION} &$\bullet$&$\bullet$& &\texttt{char *}&
+ Imposta l'algoritmo per il controllo della congestione.\\
+ \hline
+ \end{tabular}
+ \caption{Le opzioni per i socket TCP disponibili al livello
+ \const{SOL\_TCP}.}
+ \label{tab:sock_opt_tcplevel}
+\end{table}
+
+Le descrizioni delle varie opzioni riportate in
+tab.~\ref{tab:sock_opt_tcplevel} sono estremamente sintetiche ed indicative,
+la spiegazione del funzionamento delle singole opzioni con una maggiore
+quantità di dettagli è fornita nel seguente elenco:
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+
+
+\item[\const{TCP\_NODELAY}] il protocollo TCP utilizza un meccanismo di
+ bufferizzazione dei dati uscenti, per evitare la trasmissione di tanti
+ piccoli segmenti con un utilizzo non ottimale della banda
+ disponibile.\footnote{il problema è chiamato anche \textit{silly window
+ syndrome}, per averne un'idea si pensi al risultato che si ottiene
+ quando un programma di terminale invia un segmento TCP per ogni tasto
+ premuto, 40 byte di intestazione di protocollo con 1 byte di dati
+ trasmessi; per evitare situazioni del genere è stato introdotto
+ \index{algoritmo~di~Nagle} l'\textsl{algoritmo di Nagle}.} Questo
+ meccanismo è controllato da un apposito algoritmo (detto
+ \index{algoritmo~di~Nagle} \textsl{algoritmo di Nagle}, vedi
+ sez.~\ref{sez:tcp_protocol_xxx}). Il comportamento normale del protocollo
+ prevede che i dati siano accumulati fintanto che non si raggiunge una
+ quantità considerata adeguata per eseguire la trasmissione di un singolo
+ segmento.
+
+ Ci sono però delle situazioni in cui questo comportamento può non essere
+ desiderabile, ad esempio quando si sa in anticipo che l'applicazione invierà
+ soltanto un piccolo quantitativo di dati;\footnote{è il caso classico di una
+ richiesta HTTP.} in tal caso l'attesa introdotta dall'algoritmo di
+ bufferizzazione non soltanto è inutile, ma peggiora le prestazioni
+ introducendo un ritardo. Impostando questa opzione si disabilita l'uso
+ \index{algoritmo~di~Nagle} dell'\textsl{algoritmo di Nagle} ed i dati
+ vengono inviati immediatamente in singoli segmenti, qualunque sia la loro
+ dimensione. Ovviamente l'uso di questa opzione è dedicato a chi ha esigenze
+ particolari come quella illustrata, che possono essere stabilite solo per la
+ singola applicazione.
+
+ Si tenga conto che questa opzione viene sovrascritta dall'eventuale
+ impostazione dell'opzione \const{TCP\_CORK} (il cui scopo è sostanzialmente
+ l'opposto) che blocca l'invio immediato. Tuttavia quando la si abilita viene
+ sempre forzato lo scaricamento della coda di invio (con conseguente
+ trasmissione di tutti i dati pendenti), anche qualora si fosse già abilitata
+ \const{TCP\_CORK}.\footnote{si tenga presente però che \const{TCP\_CORK} può
+ essere specificata insieme a \const{TCP\_NODELAY} soltanto a partire dal
+ kernel 2.5.71.}
+
+\item[\const{TCP\_MAXSEG}] con questa opzione si legge o si imposta il valore
+ della \itindex{Maximum~Segment~Size} MSS (\textit{Maximum~Segment~Size},
+ vedi sez.~\ref{sec:net_lim_dim} e sez.~\ref{sez:tcp_protocol_xxx}) dei
+ segmenti TCP uscenti. Se l'opzione è impostata prima di stabilire la
+ connessione, si cambia anche il valore della \itindex{Maximum~Segment~Size}
+ MSS annunciata all'altro capo della connessione. Se si specificano valori
+ maggiori della \itindex{Maximum~Transfer~Unit} MTU questi verranno ignorati,
+ inoltre TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
+
+\item[\const{TCP\_CORK}] questa opzione è il complemento naturale di
+ \const{TCP\_NODELAY} e serve a gestire a livello applicativo la situazione
+ opposta, cioè quella in cui si sa fin dal principio che si dovranno inviare
+ grosse quantità di dati. Anche in questo caso \index{algoritmo~di~Nagle}
+ l'\textsl{algoritmo di Nagle} tenderà a suddividerli in dimensioni da lui
+ ritenute opportune,\footnote{l'algoritmo cerca di tenere conto di queste
+ situazioni, ma essendo un algoritmo generico tenderà comunque ad
+ introdurre delle suddivisioni in segmenti diversi, anche quando potrebbero
+ non essere necessarie, con conseguente spreco di banda.} ma sapendo fin
+ dall'inizio quale è la dimensione dei dati si potranno di nuovo ottenere
+ delle migliori prestazioni disabilitandolo, e gestendo direttamente l'invio
+ del nostro blocco di dati in soluzione unica.
+
+ Quando questa opzione viene abilitata non vengono inviati segmenti di dati
+ fintanto che essa non venga disabilitata; a quel punto tutti i dati rimasti
+ in coda saranno inviati in un solo segmento TCP. In sostanza con questa
+ opzione si può controllare il flusso dei dati mettendo una sorta di
+ ``\textsl{tappo}'' (da cui il nome in inglese) al flusso di uscita, in modo
+ ottimizzare a mano l'uso della banda. Si tenga presente che per l'effettivo
+ funzionamento ci si deve ricordare di disattivare l'opzione al termine
+ dell'invio del blocco dei dati.
+
+ Si usa molto spesso \const{TCP\_CORK} quando si effettua il trasferimento
+ diretto di un blocco di dati da un file ad un socket con \func{sendfile}
+ (vedi sez.~\ref{sec:file_sendfile_splice}), per inserire una intestazione
+ prima della chiamata a questa funzione; senza di essa l'intestazione
+ potrebbe venire spedita in un segmento a parte, che a seconda delle
+ condizioni potrebbe richiedere anche una risposta di ACK, portando ad una
+ notevole penalizzazione delle prestazioni.
+
+ Si tenga presente che l'implementazione corrente di \const{TCP\_CORK} non
+ consente di bloccare l'invio dei dati per più di 200 millisecondi, passati i
+ quali i dati accumulati in coda sanno inviati comunque. Questa opzione è
+ tipica di Linux\footnote{l'opzione è stata introdotta con i kernel della
+ serie 2.4.x.} e non è disponibile su tutti i kernel unix-like, pertanto
+ deve essere evitata se si vuole scrivere codice portabile.
+
+\item[\const{TCP\_KEEPIDLE}] con questa opzione si legge o si imposta
+ l'intervallo di tempo, in secondi, che deve trascorrere senza traffico sul
+ socket prima che vengano inviati, qualora si sia attivata su di esso
+ l'opzione \const{SO\_KEEPALIVE}, i messaggi di \textit{keep-alive} (si veda
+ la trattazione relativa al \textit{keep-alive} in
+ sez.~\ref{sec:sock_options_main}). Anche questa opzione non è disponibile
+ su tutti i kernel unix-like e deve essere evitata se si vuole scrivere
+ codice portabile.
+
+\item[\const{TCP\_KEEPINTVL}] con questa opzione si legge o si imposta
+ l'intervallo di tempo, in secondi, fra due messaggi di \textit{keep-alive}
+ successivi (si veda sempre quanto illustrato in
+ sez.~\ref{sec:sock_options_main}). Come la precedente non è disponibile su
+ tutti i kernel unix-like e deve essere evitata se si vuole scrivere codice
+ portabile.
+
+\item[\const{TCP\_KEEPCNT}] con questa opzione si legge o si imposta il numero
+ totale di messaggi di \textit{keep-alive} da inviare prima di concludere che
+ la connessione è caduta per assenza di risposte ad un messaggio di
+ \textit{keep-alive} (di nuovo vedi sez.~\ref{sec:sock_options_main}). Come
+ la precedente non è disponibile su tutti i kernel unix-like e deve essere
+ evitata se si vuole scrivere codice portabile.
+
+\item[\const{TCP\_SYNCNT}] con questa opzione si legge o si imposta il numero
+ di tentativi di ritrasmissione dei segmenti SYN usati nel
+ \itindex{three~way~handshake} \textit{three way handshake} prima che il
+ tentativo di connessione venga abortito (si ricordi quanto accennato in
+ sez.~\ref{sec:TCP_func_connect}). Sovrascrive per il singolo socket il valore
+ globale impostato con la \textit{sysctl} \texttt{tcp\_syn\_retries} (vedi
+ sez.~\ref{sec:sock_ipv4_sysctl}). Non vengono accettati valori maggiori di
+ 255; anche questa opzione non è standard e deve essere evitata se si vuole
+ scrivere codice portabile.
+
+\item[\const{TCP\_LINGER2}] con questa opzione si legge o si imposta, in
+ numero di secondi, il tempo di sussistenza dei socket terminati nello stato
+ \texttt{FIN\_WAIT2} (si ricordi quanto visto in
+ sez.~\ref{sec:TCP_conn_term}).\footnote{si tenga ben presente che questa
+ opzione non ha nulla a che fare con l'opzione \const{SO\_LINGER} che
+ abbiamo visto in sez.~\ref{sec:sock_options_main}.} Questa opzione
+ consente di sovrascrivere per il singolo socket il valore globale impostato
+ con la \textit{sysctl} \texttt{tcp\_fin\_timeout} (vedi
+ sez.~\ref{sec:sock_ipv4_sysctl}). Anche questa opzione è da evitare se si
+ ha a cuore la portabilità del codice.
+
+\item[\const{TCP\_DEFER\_ACCEPT}] questa opzione consente di modificare il
+ comportamento standard del protocollo TCP nello stabilirsi di una
+ connessione; se ricordiamo il meccanismo del \itindex{three~way~handshake}
+ \textit{three way handshake} illustrato in fig.~\ref{fig:TCP_TWH} possiamo
+ vedere che in genere un client inizierà ad inviare i dati ad un server solo
+ dopo l'emissione dell'ultimo segmento di ACK.
+
+ Di nuovo esistono situazioni (e la più tipica è quella di una richiesta
+ HTTP) in cui sarebbe utile inviare immediatamente la richiesta all'interno
+ del segmento con l'ultimo ACK del \itindex{three~way~handshake}
+ \textit{three way handshake}; si potrebbe così risparmiare l'invio di un
+ segmento successivo per la richiesta e il ritardo sul server fra la
+ ricezione dell'ACK e quello della richiesta.
+
+ Se si invoca \const{TCP\_DEFER\_ACCEPT} su un socket dal lato client (cioè
+ dal lato da cui si invoca \func{connect}) si istruisce il kernel a non
+ inviare immediatamente l'ACK finale del \itindex{three~way~handshake}
+ \textit{three way handshake}, attendendo per un po' di tempo la prima
+ scrittura, in modo da inviare i dati di questa insieme col segmento ACK.
+ Chiaramente la correttezza di questo comportamento dipende in maniera
+ diretta dal tipo di applicazione che usa il socket; con HTTP, che invia una
+ breve richiesta, permette di risparmiare un segmento, con FTP, in cui invece
+ si attende la ricezione del prompt del server, introduce un inutile ritardo.
+
+ Allo stesso tempo il protocollo TCP prevede che sul lato del server la
+ funzione \func{accept} ritorni dopo la ricezione dell'ACK finale, in tal
+ caso quello che si fa usualmente è lanciare un nuovo processo per leggere i
+ successivi dati, che si bloccherà su una \func{read} se questi non sono
+ disponibili; in questo modo si saranno impiegate delle risorse (per la
+ creazione del nuovo processo) che non vengono usate immediatamente. L'uso
+ di \const{TCP\_DEFER\_ACCEPT} consente di intervenire anche in questa
+ situazione; quando la si invoca sul lato server (vale a dire su un socket in
+ ascolto) l'opzione fa sì che \func{accept} ritorni soltanto quando sono
+ presenti dei dati sul socket, e non alla ricezione dell'ACK conclusivo del
+ \itindex{three~way~handshake} \textit{three way handshake}.
+
+ L'opzione prende un valore intero che indica il numero massimo di secondi
+ per cui mantenere il ritardo, sia per quanto riguarda il ritorno di
+ \func{accept} su un server, che per l'invio dell'ACK finale insieme ai dati
+ su un client. L'opzione è specifica di Linux non deve essere utilizzata in
+ codice che vuole essere portabile.\footnote{su FreeBSD è presente una
+ opzione \texttt{SO\_ACCEPTFILTER} che consente di ottenere lo stesso
+ comportamento di \const{TCP\_DEFER\_ACCEPT} per quanto riguarda il lato
+ server.}
+
+\item[\const{TCP\_WINDOW\_CLAMP}] con questa opzione si legge o si imposta
+ alla dimensione specificata, in byte, il valore dichiarato della
+ \itindex{advertised~window} \textit{advertised window} (vedi
+ sez.~\ref{sez:tcp_protocol_xxx}). Il kernel impone comunque una dimensione
+ minima pari a \texttt{SOCK\_MIN\_RCVBUF/2}. Questa opzione non deve essere
+ utilizzata in codice che vuole essere portabile.