+\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{sec: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{sec: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{sec: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.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/tcp_info.h}
+ \end{minipage}
+ \caption{La struttura \structd{tcp\_info} contenente le informazioni sul
+ socket restituita dall'opzione \const{TCP\_INFO}.}
+ \label{fig:tcp_info_struct}
+\end{figure}
+
+\item[\const{TCP\_INFO}] questa opzione, specifica di Linux, ma introdotta
+ anche in altri kernel (ad esempio FreeBSD) permette di controllare lo stato
+ interno di un socket TCP direttamente da un programma in user space.
+ L'opzione restituisce in una speciale struttura \struct{tcp\_info}, la cui
+ definizione è riportata in fig.~\ref{fig:tcp_info_struct}, tutta una serie
+ di dati che il kernel mantiene, relativi al socket. Anche questa opzione
+ deve essere evitata se si vuole scrivere codice portabile.
+
+ Con questa opzione diventa possibile ricevere una serie di informazioni
+ relative ad un socket TCP così da poter effettuare dei controlli senza dover
+ passare attraverso delle operazioni di lettura. Ad esempio si può verificare
+ se un socket è stato chiuso usando una funzione analoga a quella illustrata
+ in fig.~\ref{fig:is_closing}, in cui si utilizza il valore del campo
+ \var{tcpi\_state} di \struct{tcp\_info} per controllare lo stato del socket.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/is_closing.c}
+ \end{minipage}
+ \caption{Codice della funzione \texttt{is\_closing.c}, che controlla lo stato
+ di un socket TCP per verificare se si sta chiudendo.}
+ \label{fig:is_closing}
+\end{figure}
+
+%Si noti come nell'esempio si sia (
+
+
+\item[\const{TCP\_QUICKACK}] con questa opzione è possibile eseguire una forma
+ di controllo sull'invio dei segmenti ACK all'interno di in flusso di dati su
+ TCP. In genere questo invio viene gestito direttamente dal kernel, il
+ comportamento standard, corrispondente la valore logico di vero (in genere
+ 1) per questa opzione, è quello di inviare immediatamente i segmenti ACK, in
+ quanto normalmente questo significa che si è ricevuto un blocco di dati e si
+ può passare all'elaborazione del blocco successivo.
+
+ Qualora però la nostra applicazione sappia in anticipo che alla ricezione di
+ un blocco di dati seguirà immediatamente l'invio di un altro
+ blocco,\footnote{caso tipico ad esempio delle risposte alle richieste HTTP.}
+ poter accorpare quest'ultimo al segmento ACK permette di risparmiare sia in
+ termini di dati inviati che di velocità di risposta. Per far questo si può
+ utilizzare \const{TCP\_QUICKACK} impostando un valore logico falso (cioè 0),
+ in questo modo il kernel attenderà così da inviare il prossimo segmento di
+ ACK insieme ai primi dati disponibili.
+
+ Si tenga presente che l'opzione non è permanente, vale a dire che una volta
+ che la si sia impostata a 0 il kernel la riporterà al valore di default dopo
+ il suo primo utilizzo. Sul lato server la si può impostare anche una volta
+ sola su un socket in ascolto, ed essa verrà ereditata da tutti i socket che
+ si otterranno da esso al ritorno di \func{accept}.
+
+% TODO trattare con gli esempi di apache
+
+\item[\const{TCP\_CONGESTION}] questa opzione permette di impostare quale
+ algoritmo per il controllo della congestione\footnote{il controllo della
+ congestione è un meccanismo previsto dal protocollo TCP (vedi
+ sez.~\ref{sec:tcp_protocol_xxx}) per evitare di trasmettere inutilmente
+ dati quando una connessione è congestionata; un buon algoritmo è
+ fondamentale per il funzionamento del protocollo, dato che i pacchetti
+ persi andrebbero ritrasmessi, per cui inviare un pacchetto su una linea
+ congestionata potrebbe causare facilmente un peggioramento della
+ situazione.} utilizzare per il singolo socket. L'opzione è stata
+ introdotta con il kernel 2.6.13,\footnote{alla data di stesura di queste
+ note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
+ definita nelle intestazioni delle \acr{glibc} per cui occorre definirla a
+ mano al suo valore che è 13.} e prende come per \param{optval} il
+ puntatore ad un buffer contenente il nome dell'algoritmo di controllo che
+ si vuole usare.
+
+ L'uso di un nome anziché di un valore numerico è dovuto al fatto che gli
+ algoritmi di controllo della congestione sono realizzati attraverso
+ altrettanti moduli del kernel, e possono pertanto essere attivati a
+ richiesta; il nome consente di caricare il rispettivo modulo e di introdurre
+ moduli aggiuntivi che implementino altri meccanismi.
+
+ Per poter disporre di questa funzionalità occorre aver compilato il kernel
+ attivando l'opzione di configurazione generale
+ \texttt{TCP\_CONG\_ADVANCED},\footnote{disponibile come \textit{TCP:
+ advanced congestion control} nel menù \textit{Network->Networking
+ options}, che a sua volta renderà disponibile un ulteriore menù con gli
+ algoritmi presenti.} e poi abilitare i singoli moduli voluti con le varie
+ \texttt{TCP\_CONG\_*} presenti per i vari algoritmi disponibili; un elenco
+ di quelli attualmente supportati nella versione ufficiale del kernel è
+ riportato in tab.~\ref{tab:sock_tcp_congestion_algo}.\footnote{la lista è
+ presa dalla versione 2.6.17.}
+
+
+ Si tenga presente che prima della implementazione modulare alcuni di questi
+ algoritmi erano disponibili soltanto come caratteristiche generali del
+ sistema, attivabili per tutti i socket, questo è ancora possibile con la
+ \textit{sysctl} \texttt{tcp\_congestion\_control} (vedi
+ sez.~\ref{sec:sock_ipv4_sysctl}) che ha sostituito le precedenti
+ \textit{sysctl}.\footnote{riportate anche, alla data di stesura di queste
+ pagine (Set. 2006) nelle pagine di manuale, ma non più presenti.}
+
+ \begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|p{10cm}|}
+ \hline
+ \textbf{Nome}&\textbf{Configurazione}&\textbf{Riferimento} \\
+ \hline
+ \hline
+ reno& -- &Algoritmo tradizionale, usato in caso di assenza degli altri.\\
+ \texttt{bic} &\texttt{TCP\_CONG\_BIC} &
+ \href{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm}
+ {\textsf{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm}}.\\
+ \texttt{cubic} &\texttt{TCP\_CONG\_CUBIC} &
+ \href{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm}
+ {\textsf{http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm}}.\\
+ \texttt{highspeed}&\texttt{TCP\_CONG\_HSTCP} &
+ \href{http://www.icir.org/floyd/hstcp.html}
+ {\textsf{http://www.icir.org/floyd/hstcp.html}}.\\
+ \texttt{htcp} &\texttt{TCP\_CONG\_HTCP} &
+ \href{http://www.hamilton.ie/net/htcp/}
+ {\textsf{http://www.hamilton.ie/net/htcp/}}.\\
+ \texttt{hybla} &\texttt{TCP\_CONG\_HYBLA} &
+ \href{http://www.danielinux.net/projects.html}
+ {\textsf{http://www.danielinux.net/projects.html}}.\\
+ \texttt{scalable}&\texttt{TCP\_CONG\_SCALABLE}&
+ \href{http://www.deneholme.net/tom/scalable/}
+ {\textsf{http://www.deneholme.net/tom/scalable/}}.\\
+ \texttt{vegas} &\texttt{TCP\_CONG\_VEGAS} &
+ \href{http://www.cs.arizona.edu/protocols/}
+ {\textsf{http://www.cs.arizona.edu/protocols/}}.\\
+ \texttt{westwood}&\texttt{TCP\_CONG\_WESTWOOD}&
+ \href{http://www.cs.ucla.edu/NRL/hpi/tcpw/}
+ {\textsf{http://www.cs.ucla.edu/NRL/hpi/tcpw/}}.\\
+% \texttt{}&\texttt{}& .\\
+ \hline
+ \end{tabular}
+ \caption{Gli algoritmi per il controllo della congestione disponibili con
+ Linux con le relative opzioni di configurazione da attivare.}
+ \label{tab:sock_tcp_congestion_algo}
+ \end{table}
+
+\end{basedescript}
+
+
+Il protocollo UDP, anche per la sua maggiore semplicità, supporta un numero
+ridotto di opzioni, riportate in tab.~\ref{tab:sock_opt_udplevel}; anche in
+questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
+l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
+\const{IPPROTO\_UDP}). Le costanti che identificano dette opzioni sono
+definite in \file{netinet/udp.h}, ed accessibili includendo detto
+file.\footnote{come per TCP, la definizione delle opzioni effettivamente
+ supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
+ quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_udplevel}.}
+
+\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{UDP\_CORK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& %???
+ Accumula tutti i dati su un unico pacchetto.\\
+ \const{UDP\_ENCAP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& %???
+ Non documentata.\\
+ \hline
+ \end{tabular}
+ \caption{Le opzioni per i socket UDP disponibili al livello
+ \const{SOL\_UDP}.}
+ \label{tab:sock_opt_udplevel}
+\end{table}
+
+% TODO documentare \const{UDP\_ENCAP}
+
+Ancora una volta le descrizioni contenute tab.~\ref{tab:sock_opt_udplevel}
+sono un semplice riferimento, una maggiore quantità di dettagli sulle
+caratteristiche delle opzioni citate è quello dell'elenco seguente:
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\const{UDP\_CORK}] questa opzione ha l'identico effetto dell'analoga
+ \const{TCP\_CORK} vista in precedenza per il protocollo TCP, e quando
+ abilitata consente di accumulare i dati in uscita su un solo pacchetto che
+ verrà inviato una volta che la si disabiliti. L'opzione è stata introdotta
+ con il kernel 2.5.44, e non deve essere utilizzata in codice che vuole
+ essere portabile.
+
+\item[\const{UDP\_ENCAP}] Questa opzione permette di gestire l'incapsulazione
+ dei dati nel protocollo UDP. L'opzione è stata introdotta con il kernel
+ 2.5.67, e non è documentata. Come la precedente è specifica di Linux e non
+ deve essere utilizzata in codice portabile.
+
+\end{basedescript}
+
+
+
+