X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=8118b1e49db1067d5ae69627623a2daac271e736;hp=9cd9ab726b0c94f549525ab157f5c4164479230a;hb=beece18eba2dcc2a9b915dab61277df8685a3da6;hpb=193d612d40c5f81f5559ea6e11e70f6b6e51fb39

diff --git a/tcpsock.tex b/tcpsock.tex
index 9cd9ab7..8118b1e 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -1,6 +1,6 @@
 %% tcpsock.tex
 %%
-%% Copyright (C) 2000-2011 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2014 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -95,9 +95,8 @@ stabilisce la connessione.
 % conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è
 % quando si risponde al telefono.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=10cm]{img/three_way_handshake}  
+\begin{figure}[!htb]
+  \centering \includegraphics[width=10cm]{img/three_way_handshake}  
   \caption{Il \textit{three way handshake} del TCP.}
   \label{fig:TCP_TWH}
 \end{figure}
@@ -136,12 +135,13 @@ comunicare all'altro capo una serie di parametri utili a regolare la
 connessione.  Normalmente vengono usate le seguenti opzioni:
 
 \begin{itemize}
-\item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
-  \textit{Maximum Segment Size}, con questa opzione ciascun capo della
-  connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
-  accettare per ciascun segmento nella connessione corrente. È possibile
-  leggere e scrivere questo valore attraverso l'opzione del socket
-  \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}).
+\item \textit{MSS option}, dove MMS sta per
+  \itindex{Maximum~Segment~Size~(MSS)} \textit{Maximum Segment Size}, con
+  questa opzione ciascun capo della connessione annuncia all'altro il massimo
+  ammontare di dati che vorrebbe accettare per ciascun segmento nella
+  connessione corrente. È possibile leggere e scrivere questo valore
+  attraverso l'opzione del socket \const{TCP\_MAXSEG} (vedi
+  sez.~\ref{sec:sock_tcp_udp_options}).
   
 \item \textit{window scale option}, il protocollo TCP implementa il controllo
   di flusso attraverso una \itindex{advertised~window} \textit{advertised
@@ -180,8 +180,8 @@ connessione.  Normalmente vengono usate le seguenti opzioni:
 
 \end{itemize}
 
-La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
-le implementazioni del protocollo, le ultime due opzioni (trattate
+La MSS \itindex{Maximum~Segment~Size~(MSS)} è generalmente supportata da quasi
+tutte le implementazioni del protocollo, le ultime due opzioni (trattate
 nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
 vengono anche dette \textit{long fat pipe options} dato che questo è il nome
 che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
@@ -225,9 +225,8 @@ effettua la chiusura passiva, siano accorpati in un singolo segmento. In
 fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
 scambio dei segmenti che conclude la connessione.
 
-\begin{figure}[htb]
-  \centering  
-  \includegraphics[width=10cm]{img/tcp_close}  
+\begin{figure}[!htb]
+  \centering \includegraphics[width=10cm]{img/tcp_close}  
   \caption{La chiusura di una connessione TCP.}
   \label{fig:TCP_close}
 \end{figure}
@@ -299,17 +298,16 @@ In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
 pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
 che il protocollo viene ad assumere per i due lati, server e client.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=9cm]{img/tcp_connection}  
+\begin{figure}[!htb]
+  \centering \includegraphics[width=9cm]{img/tcp_connection}  
   \caption{Schema dello scambio di pacchetti per un esempio di connessione.}
   \label{fig:TCP_conn_example}
 \end{figure}
 
 La connessione viene iniziata dal client che annuncia una
-\itindex{Maximum~Segment~Size} MSS di 1460, un valore tipico con Linux per
-IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe essere
-anche un valore diverso).
+\itindex{Maximum~Segment~Size~(MSS)} MSS di 1460, un valore tipico con Linux
+per IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe
+essere anche un valore diverso).
 
 Una volta che la connessione è stabilita il client scrive al server una
 richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
@@ -480,11 +478,10 @@ dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene
 l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
   Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
 internet (una versione aggiornata si può trovare all'indirizzo
-\href{http://www.iana.org/assignments/port-numbers}
-{\textsf{http://www.iana.org/assignments/port-numbers}}); inoltre in un
-sistema unix-like un analogo elenco viene mantenuto nel file
-\conffile{/etc/services}, con la corrispondenza fra i vari numeri di porta ed
-il nome simbolico del servizio.  I numeri sono divisi in tre intervalli:
+\url{http://www.iana.org/assignments/port-numbers}); inoltre in un sistema
+unix-like un analogo elenco viene mantenuto nel file \conffile{/etc/services},
+con la corrispondenza fra i vari numeri di porta ed il nome simbolico del
+servizio.  I numeri sono divisi in tre intervalli:
 
 \begin{enumerate*}
 \item \textsl{le porte note}. I numeri da 0 a 1023. Queste sono controllate e
@@ -510,8 +507,7 @@ fatto scelte diverse per le porte effimere, in particolare in
 fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux.
 
 \begin{figure}[!htb]
-  \centering
-  \includegraphics[width=13cm]{img/port_alloc}  
+  \centering \includegraphics[width=13cm]{img/port_alloc}  
   \caption{Allocazione dei numeri di porta.}
   \label{fig:TCP_port_alloc}
 \end{figure}
@@ -523,7 +519,7 @@ un socket solo da un processo con i privilegi di amministratore, per far sì
 che solo l'amministratore possa allocare queste porte per far partire i
 relativi servizi.
 
-Le \textsl{glibc} definiscono (in \texttt{netinet/in.h})
+Le \textsl{glibc} definiscono in \headfile{netinet/in.h}
 \const{IPPORT\_RESERVED} e \const{IPPORT\_USERRESERVED}, in cui la prima (che
 vale 1024) indica il limite superiore delle porte riservate, e la seconda (che
 vale 5000) il limite inferiore delle porte a disposizione degli utenti.  La
@@ -582,7 +578,7 @@ posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
 associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
 \cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
-definito in \file{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
+definito in \headfile{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
 
 Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
 esterna non sono specificati; in questo caso la \textit{socket pair} associata
@@ -735,7 +731,7 @@ Si noti che si è usato \func{htonl} per assegnare il valore
 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-\itindex{endianess} l'\textit{endianess} della macchina, ed anche se esse
+\itindex{endianness} l'\textit{endianness} della macchina, ed anche se esse
 possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
 norma usare sempre la funzione \func{htonl}.
 
@@ -765,7 +761,7 @@ metodo con IPv6, in cui l'indirizzo deve necessariamente essere specificato
 con una struttura, perché il linguaggio C non consente l'uso di una struttura
 costante come operando a destra in una assegnazione.
 
-Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
+Per questo motivo nell'header \headfile{netinet/in.h} è definita una variabile
 \macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
@@ -843,7 +839,7 @@ nella chiamata della funzione sono le seguenti:
   secondi per un numero di volte che può essere stabilito dall'utente. Questo
   può essere fatto a livello globale con una opportuna
   \func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in
-    \procfile{/proc/sys/net/ipv4/tcp\_syn\_retries}, vedi
+    \sysctlfile{net/ipv4/tcp\_syn\_retries}, vedi
     sez.~\ref{sec:sock_ipv4_sysctl}.} e a livello di singolo socket con
   l'opzione \const{TCP\_SYNCNT} (vedi sez.~\ref{sec:sock_tcp_udp_options}). Il
   valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
@@ -950,9 +946,8 @@ nella coda delle connessioni complete è passata al programma, o, se la coda è
 vuota, il processo viene posto in attesa e risvegliato all'arrivo della prima
 connessione completa.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=11cm]{img/tcp_listen_backlog}  
+\begin{figure}[!htb]
+  \centering \includegraphics[width=11cm]{img/tcp_listen_backlog}  
   \caption{Schema di funzionamento delle code delle connessioni complete ed
     incomplete.}
   \label{fig:TCP_listen_backlog}
@@ -978,9 +973,9 @@ indicare la lunghezza della coda delle connessioni complete. La lunghezza
 della coda delle connessioni incomplete può essere ancora controllata usando
 la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
 o scrivendola direttamente in
-\procfile{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}.  Quando si attiva la
+\sysctlfile{net/ipv4/tcp\_max\_syn\_backlog}.  Quando si attiva la
 protezione dei syncookies però (con l'opzione da compilare nel kernel e da
-attivare usando \procfile{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
+attivare usando \sysctlfile{net/ipv4/tcp\_syncookies}) questo valore
 viene ignorato e non esiste più un valore massimo.  In ogni caso in Linux il
 valore di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se
 è superiore a detta costante (che di default vale 128).\footnote{il valore di
@@ -1106,8 +1101,9 @@ eventualmente ripetere la chiamata alla funzione come per l'errore di
 Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
 i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale
   tutti quelli che si possono impostare con \func{fcntl}, vedi
-  sez.~\ref{sec:file_fcntl}.} che devono essere rispecificati ogni volta. Tutto
-questo deve essere tenuto in conto se si devono scrivere programmi portabili.
+  sez.~\ref{sec:file_fcntl_ioctl}.} che devono essere rispecificati ogni
+volta. Tutto questo deve essere tenuto in conto se si devono scrivere
+programmi portabili.
 
 Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
 funzionamento di un server: in generale infatti c'è sempre un solo socket in
@@ -1227,9 +1223,9 @@ socket BSD fanno questa assunzione.
 \subsection{La funzione \func{close}}
 \label{sec:TCP_func_close}
 
-La funzione standard Unix \func{close} (vedi sez.~\ref{sec:file_close}) che si
-usa sui file può essere usata con lo stesso effetto anche sui file descriptor
-associati ad un socket.
+La funzione standard Unix \func{close} (vedi sez.~\ref{sec:file_open_close})
+che si usa sui file può essere usata con lo stesso effetto anche sui file
+descriptor associati ad un socket.
 
 L'azione di questa funzione quando applicata a socket è di marcarlo come
 chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
@@ -1246,9 +1242,9 @@ Come per tutti i file descriptor anche per i socket viene mantenuto un numero
 di riferimenti, per cui se più di un processo ha lo stesso socket aperto
 l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
 fintanto che il numero di riferimenti non si annulla, questo si applica, come
-visto in sez.~\ref{sec:file_sharing}, sia ai file descriptor duplicati che a
-quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
-si aspetta in una qualunque applicazione client/server.
+visto in sez.~\ref{sec:file_shared_access}, sia ai file descriptor duplicati
+che a quelli ereditati dagli eventuali processi figli, ed è il comportamento
+che ci si aspetta in una qualunque applicazione client/server.
 
 Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
 descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
@@ -1288,9 +1284,9 @@ problema si avverte solo in lettura, quando si incontra la fine del file. In
 generale non è così, e con i socket questo è particolarmente evidente.
 
 
-\begin{figure}[htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/FullRead.c}
   \end{minipage} 
   \normalsize
@@ -1315,10 +1311,10 @@ fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
 \file{FullWrite.c}.
 
-\begin{figure}[htb]
+\begin{figure}[!htbp]
   \centering
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/FullWrite.c}
   \end{minipage} 
   \normalsize
@@ -1329,9 +1325,10 @@ disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
 
 Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
 fino all'esaurimento del numero di byte richiesti, in caso di errore viene
-controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
-call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
-l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
+controllato se questo è \errcode{EINTR} (cioè un'interruzione della
+\textit{system call} dovuta ad un segnale), nel qual caso l'accesso viene
+ripetuto, altrimenti l'errore viene ritornato al programma chiamante,
+interrompendo il ciclo.
 
 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
 arrivati alla fine del file (per i socket questo significa in genere che
@@ -1359,9 +1356,9 @@ funzione per stampare un messaggio di aiuto) è allegato alla guida nella
 sezione dei codici sorgente e può essere compilato su una qualunque macchina
 GNU/Linux.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_daytime.c}
   \end{minipage} 
   \normalsize
@@ -1389,7 +1386,7 @@ il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
 inizializzare tutto a zero, per poi inserire il tipo di indirizzo
 (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
 la funzione \func{htons} per convertire il formato dell'intero usato dal
-computer a quello usato nella rete, infine \texttt{\small 23--27} si può
+computer a quello usato nella rete, infine (\texttt{\small 23--27}) si può
 utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
 passato dalla linea di comando.
 
@@ -1459,7 +1456,7 @@ esempi.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_iter_daytimed.c}
   \end{minipage} 
   \normalsize
@@ -1542,8 +1539,8 @@ quello in questione, non è opportuno bloccare un server nel servizio di un
 client per volta; per questo si ricorre alle capacità di multitasking del
 sistema.
 
-Come accennato anche in sez.~\ref{sec:proc_gen} una delle modalità più comuni
-di funzionamento da parte dei server è quella di usare la funzione \func{fork}
+Come spiegato in sez.~\ref{sec:proc_fork} una delle modalità più comuni di
+funzionamento da parte dei server è quella di usare la funzione \func{fork}
 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
 incarichi della gestione della comunicazione.  Si è allora riscritto il server
 \textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
@@ -1556,9 +1553,9 @@ riguardante l'apertura passiva del socket). Al solito il sorgente completo del
 server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
 sorgenti degli altri esempi.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_cunc_daytimed.c}
   \end{minipage} 
   \normalsize
@@ -1696,9 +1693,9 @@ client per il servizio \textit{daytime} (vedi
 sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
 è sostanzialmente identica, a parte l'uso di una porta diversa.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6 cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_echo_first.c}
   \end{minipage} 
   \normalsize
@@ -1744,9 +1741,9 @@ buffer di ricezione e viene inserita (\texttt{\small 8}) la terminazione della
 stringa e per poter usare (\texttt{\small 9}) la funzione \func{fputs} per
 scriverli su \file{stdout}.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ClientEcho_first.c}
   \end{minipage} 
   \normalsize
@@ -1781,7 +1778,7 @@ sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_echod_first.c}
   \end{minipage} 
   \normalsize
@@ -1861,9 +1858,9 @@ in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
 (\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
 standard error.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/PrintErr.c}
   \end{minipage} 
   \normalsize
@@ -1885,9 +1882,9 @@ si incarica di tenere conto automaticamente della possibilità che non tutti i
 dati di cui è richiesta la scrittura vengano trasmessi con una singola
 \func{write}.
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ServEcho_first.c}
   \end{minipage} 
   \normalsize
@@ -2015,7 +2012,7 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
   restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
   così la funzione \code{ClientEcho} ritorna.
 \item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
-  come parte del processo terminazione tutti i file descriptor vengono chiusi
+  come parte del processo di terminazione tutti i file descriptor vengono chiusi
   (si ricordi quanto detto in sez.~\ref{sec:proc_term_conclusion}); questo
   causa la chiusura del socket di comunicazione; il client allora invierà un
   FIN al server a cui questo risponderà con un ACK.  A questo punto il client
@@ -2040,22 +2037,22 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
-del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
+del segnale \signal{SIGCHLD} al padre, ma dato che non si è installato un
 gestore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
-(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
-ripetendo il comando \cmd{ps}:
+otterremo che il processo figlio entrerà nello stato di \itindex{zombie}
+\textit{zombie} (si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}),
+come risulterà ripetendo il comando \cmd{ps}:
 \begin{verbatim}
  2356 pts/0    S      0:00 ./echod
  2359 pts/0    Z      0:00 [echod <defunct>]
 \end{verbatim}
 
-Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
-ricevere opportunamente lo stato di terminazione del processo (si veda
-sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
-quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al nostro
-server è pertanto quella di inserire la gestione della terminazione dei
+Dato che non è il caso di lasciare processi \itindex{zombie} \textit{zombie},
+occorrerà ricevere opportunamente lo stato di terminazione del processo (si
+veda sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
+secondo quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al
+nostro server è pertanto quella di inserire la gestione della terminazione dei
 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
 \code{Signal} (che abbiamo illustrato in fig.~\ref{fig:sig_Signal_code}), per
 installare il gestore che riceve i segnali dei processi figli terminati già
@@ -2066,69 +2063,69 @@ all'esempio illustrato in fig.~\ref{fig:TCP_echo_server_first_code}.
 
 In questo modo però si introduce un altro problema. Si ricordi infatti che,
 come spiegato in sez.~\ref{sec:sig_gen_beha}, quando un programma si trova in
-stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene
-interrotta alla ricezione di un segnale. Per questo motivo, alla fine
-dell'esecuzione del gestore del segnale, se questo ritorna, il programma
-riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
-di \errcode{EINTR}.
+stato di \texttt{sleep} durante l'esecuzione di una \textit{system call},
+questa viene interrotta alla ricezione di un segnale. Per questo motivo, alla
+fine dell'esecuzione del gestore del segnale, se questo ritorna, il programma
+riprenderà l'esecuzione ritornando dalla \textit{system call} interrotta con
+un errore di \errcode{EINTR}.
 
 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
 client, il processo figlio che gestisce la connessione terminerà, ed il padre,
-per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
-eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
-padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
-un caso fortuito in cui il segnale arriva durante l'esecuzione del programma
-in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo
-previsto questa eventualità il programma considera questo un errore fatale
-terminando a sua volta con un messaggio del tipo:
+per evitare la creazione di \itindex{zombie} \textit{zombie}, riceverà il
+segnale \signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore
+però l'esecuzione nel padre ripartirà subito con il ritorno della funzione
+\func{accept} (a meno di un caso fortuito in cui il segnale arriva durante
+l'esecuzione del programma in risposta ad una connessione) con un errore di
+\errcode{EINTR}. Non avendo previsto questa eventualità il programma considera
+questo un errore fatale terminando a sua volta con un messaggio del tipo:
 \begin{verbatim}
 [root@gont sources]# ./echod -i
 accept error: Interrupted system call
 \end{verbatim}%#
 
 Come accennato in sez.~\ref{sec:sig_gen_beha} le conseguenze di questo
-comportamento delle system call possono essere superate in due modi diversi,
-il più semplice è quello di modificare il codice di \func{Signal} per
-richiedere il riavvio automatico delle system call interrotte secondo la
-semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
-rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora la
-nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
-  alle altre funzioni riguardanti la gestione dei segnali, nel file
+comportamento delle \textit{system call} possono essere superate in due modi
+diversi, il più semplice è quello di modificare il codice di \func{Signal} per
+richiedere il riavvio automatico delle \textit{system call} interrotte secondo
+la semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
+rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora
+la nuova funzione \func{SignalRestart}\footnote{anche questa è definita,
+  insieme alle altre funzioni riguardanti la gestione dei segnali, nel file
   \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
   allegati.} come mostrato in fig.~\ref{fig:sig_SignalRestart_code}, ed
 installeremo il gestore usando quest'ultima.
 
-\begin{figure}[!htb]
-  \footnotesize  \centering
-  \begin{minipage}[c]{15.6cm}
+\begin{figure}[!htbp]
+  \footnotesize \centering
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/SignalRestart.c}
   \end{minipage}  
   \normalsize 
   \caption{La funzione \func{SignalRestart}, che installa un gestore di
-    segnali in semantica BSD per il riavvio automatico delle system call
-    interrotte.}
+    segnali in semantica BSD per il riavvio automatico delle \textit{system
+      call} interrotte.}
   \label{fig:sig_SignalRestart_code}
 \end{figure}
 
 Come si può notare questa funzione è identica alla precedente \func{Signal},
-illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece di
-inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
+illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece
+di inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
 inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
 funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
-modifica: le system call interrotte saranno automaticamente riavviate, e
-l'errore \errcode{EINTR} non si manifesterà più.
+modifica: le \textit{system call} interrotte saranno automaticamente
+riavviate, e l'errore \errcode{EINTR} non si manifesterà più.
 
 La seconda soluzione è più invasiva e richiede di controllare tutte le volte
-l'errore restituito dalle varie system call, ripetendo la chiamata qualora
-questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
-della portabilità, infatti lo standard POSIX dice che la funzionalità di
-riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
-opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
-Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
-  parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri
-  non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
-  caso di Linux viene sempre fatta.} anche quando questa è presente, non è
-detto possa essere usata con \func{accept}. 
+l'errore restituito dalle varie \textit{system call}, ripetendo la chiamata
+qualora questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il
+pregio della portabilità, infatti lo standard POSIX dice che la funzionalità
+di riavvio automatico delle \textit{system call}, fornita da
+\const{SA\_RESTART}, è opzionale, per cui non è detto che essa sia disponibile
+su qualunque sistema.  Inoltre in certi casi,\footnote{Stevens in \cite{UNP1}
+  accenna che la maggior parte degli Unix derivati da BSD non fanno ripartire
+  \func{select}; altri non riavviano neanche \func{accept} e \func{recvfrom},
+  cosa che invece nel caso di Linux viene sempre fatta.} anche quando questa è
+presente, non è detto possa essere usata con \func{accept}.
 
 
 La portabilità nella gestione dei segnali però viene al costo di una
@@ -2141,7 +2138,7 @@ codice completo di quest'ultimo si trova nel file
 
 La prima modifica effettuata è stata quella di introdurre una nuova opzione a
 riga di comando, \texttt{-c}, che permette di richiedere il comportamento
-compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
+compatibile nella gestione di \signal{SIGCHLD} al posto della semantica BSD
 impostando la variabile \var{compat} ad un valore non nullo. Questa è
 preimpostata al valore nullo, cosicché se non si usa questa opzione il
 comportamento di default del server è di usare la semantica BSD. 
@@ -2156,21 +2153,21 @@ fig.~\ref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
 gestione di tutte queste opzioni, che può essere trovata nel sorgente del
 programma.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_echod_second.c}
   \end{minipage} 
   \normalsize
   \caption{La sezione nel codice della seconda versione del server
     per il servizio \textit{echo} modificata per tener conto dell'interruzione
-    delle system call.}
+    delle \textit{system call}.}
   \label{fig:TCP_echo_server_code_second}
 \end{figure}
 
 Vediamo allora come è cambiato il nostro server; una volta definite le
 variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
-verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
+verificare la semantica scelta per la gestione di \signal{SIGCHLD}, a seconda
 del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
 funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
 (\texttt{\small 12}), essendo quest'ultimo il valore di default.
@@ -2186,14 +2183,14 @@ eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
 numero di secondi da aspettare (il valore preimpostato è nullo).
 
 Si è potuto lasciare inalterata tutta la sezione di creazione del socket
-perché nel server l'unica chiamata ad una system call lenta, che può essere
-interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
-l'unica funzione che può mettere il processo padre in stato di sleep nel
+perché nel server l'unica chiamata ad una \textit{system call} lenta, che può
+essere interrotta dall'arrivo di \signal{SIGCHLD}, è quella ad \func{accept},
+che è l'unica funzione che può mettere il processo padre in stato di sleep nel
 periodo in cui un figlio può terminare; si noti infatti come le altre
-\index{system~call~lente} \textit{slow system call}\footnote{si ricordi la
-  distinzione fatta in sez.~\ref{sec:sig_gen_beha}.} o sono chiamate prima di
+\index{system~call~lente} \textit{system call} lente (si ricordi la
+distinzione fatta in sez.~\ref{sec:sig_gen_beha}) o sono chiamate prima di
 entrare nel ciclo principale, quando ancora non esistono processi figli, o
-sono chiamate dai figli stessi e non risentono di \const{SIGCHLD}.
+sono chiamate dai figli stessi e non risentono di \signal{SIGCHLD}.
 
 Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
   23--42}), rispetto precedente versione di fig.~\ref{fig:TCP_ServEcho_first},
@@ -2222,9 +2219,9 @@ sia per tenere conto della nuova funzionalità di debugging, che per effettuare
 un controllo in caso di errore; il codice della nuova versione è mostrato in
 fig.~\ref{fig:TCP_ServEcho_second}.
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ServEcho_second.c}
   \end{minipage} 
   \normalsize
@@ -2276,9 +2273,8 @@ connessione viene abortita sul lato client per un qualche errore di rete con
 l'invio di un segmento RST, prima che nel server sia stata chiamata la
 funzione \func{accept}.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=10cm]{img/tcp_client_early_abort}  
+\begin{figure}[!htb]
+  \centering \includegraphics[width=10cm]{img/tcp_client_early_abort}  
   \caption{Un possibile caso di terminazione precoce della connessione.}
   \label{fig:TCP_early_abort}
 \end{figure}
@@ -2297,7 +2293,7 @@ stata accettata dal programma.
 
 Questo significa che, oltre alla interruzione da parte di un segnale, che
 abbiamo trattato in sez.~\ref{sec:TCP_child_hand} nel caso particolare di
-\const{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
+\signal{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
 \func{accept}, che come nel caso precedente, necessitano semplicemente la
 ripetizione della chiamata senza che si debba uscire dal programma. In questo
 caso anche la versione modificata del nostro server non sarebbe adatta, in
@@ -2426,7 +2422,7 @@ pacchetto.  Questo causerà la ricezione dell'eco nel client che lo stamperà a
 video.
 
 A questo punto noi procediamo ad interrompere l'esecuzione del server con un
-\texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui
+\texttt{C-c} (cioè con l'invio di \signal{SIGTERM}): nel momento in cui
 facciamo questo vengono immediatamente generati altri due pacchetti. La
 terminazione del processo infatti comporta la chiusura di tutti i suoi file
 descriptor, il che comporta, per il socket che avevamo aperto, l'inizio della
@@ -2472,15 +2468,16 @@ avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket
 è una operazione lecita, per cui la nostra scrittura avrà comunque successo
 (come si può constatare lanciando usando \cmd{strace}\footnote{il comando
   \cmd{strace} è un comando di debug molto utile che prende come argomento un
-  altro comando e ne stampa a video tutte le invocazioni di una system call,
-  coi relativi argomenti e valori di ritorno, per cui usandolo in questo
-  contesto potremo verificare che effettivamente la \func{write} ha scritto la
-  riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
-programma non ha a questo punto alcun modo di sapere che dall'altra parte non
-c'è più nessuno processo in grado di leggere quanto scriverà. Questo sarà
-chiaro solo dopo il tentativo di scrittura, e la ricezione del segmento RST di
-risposta che indica che dall'altra parte non si è semplicemente chiuso un capo
-del socket, ma è completamente terminato il programma.
+  altro comando e ne stampa a video tutte le invocazioni di una \textit{system
+    call}, coi relativi argomenti e valori di ritorno, per cui usandolo in
+  questo contesto potremo verificare che effettivamente la \func{write} ha
+  scritto la riga, che in effetti è stata pure trasmessa via rete.}), in
+quanto il nostro programma non ha a questo punto alcun modo di sapere che
+dall'altra parte non c'è più nessuno processo in grado di leggere quanto
+scriverà. Questo sarà chiaro solo dopo il tentativo di scrittura, e la
+ricezione del segmento RST di risposta che indica che dall'altra parte non si
+è semplicemente chiuso un capo del socket, ma è completamente terminato il
+programma.
 
 Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
 questo è stato chiuso avremo che, come spiegato in
@@ -2497,7 +2494,7 @@ flusso dei dati, dal punto di vista del funzionamento nei confronti delle
 funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
 pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che
 tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
-aperto il lettura il processo riceve un segnale di \const{SIGPIPE}, e questo è
+aperto il lettura il processo riceve un segnale di \signal{SIGPIPE}, e questo è
 esattamente quello che avviene in questo caso, e siccome non abbiamo un
 gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
 di terminare il processo.
@@ -2508,9 +2505,9 @@ di errore, per questo dovremo riscrivere la funzione \func{ClientEcho}, in
 modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
 la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ClientEcho_second.c}
   \end{minipage} 
   \normalsize
@@ -2624,7 +2621,7 @@ Il risultato finale qui dipende dall'implementazione dello stack TCP, e nel
 caso di Linux anche dall'impostazione di alcuni dei parametri di sistema che
 si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
 in questo caso in particolare da
-\procrelfile{/proc/sys/net/ipv4}{tcp\_retries2} (vedi
+\sysctlrelfile{net/ipv4}{tcp\_retries2} (vedi
 sez.~\ref{sec:sock_ipv4_sysctl}). Questo parametro infatti specifica il numero
 di volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo
 di una connessione prima di riportare un errore di timeout.  Il valore
@@ -2832,7 +2829,7 @@ pronto per la scrittura sono le seguenti:
   bloccherà e restituirà un valore positivo pari al numero di byte accettati
   dal livello di trasporto.
 \item il lato in scrittura della connessione è stato chiuso. In questo caso
-  una operazione di scrittura sul socket genererà il segnale \const{SIGPIPE}.
+  una operazione di scrittura sul socket genererà il segnale \signal{SIGPIPE}.
 \item c'è stato un errore sul socket. In questo caso una operazione di
   scrittura non si bloccherà ma restituirà una condizione di errore ed
   imposterà opportunamente la variabile \var{errno}. Vedremo in
@@ -2898,9 +2895,9 @@ condizione di errore (con un segmento RST) il socket connesso sarà pronto in
 lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
 nostri scopi).
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ClientEcho_third.c}
   \end{minipage} 
   \normalsize
@@ -3079,23 +3076,23 @@ vuole operare e come secondo argomento un valore intero \param{how} che indica
 la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
 valori: 
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\macro{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
+\item[\const{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
   possibile leggere dati da esso, tutti gli eventuali dati trasmessi
   dall'altro capo del socket saranno automaticamente scartati dal kernel, che,
   in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
   ACK.
-\item[\macro{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
+\item[\const{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
   possibile scrivere dati su di esso. Nel caso di socket TCP la chiamata causa
   l'emissione di un segmento FIN, secondo la procedura chiamata
   \itindex{half-close} \textit{half-close}. Tutti i dati presenti nel buffer
   di scrittura prima della chiamata saranno inviati, seguiti dalla sequenza di
   chiusura illustrata in sez.~\ref{sec:TCP_conn_term}.
-\item[\macro{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
+\item[\const{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
   scrittura del socket. È equivalente alla chiamata in sequenza con
-  \macro{SHUT\_RD} e \macro{SHUT\_WR}.
+  \const{SHUT\_RD} e \const{SHUT\_WR}.
 \end{basedescript}
 
-Ci si può chiedere quale sia l'utilità di avere introdotto \macro{SHUT\_RDWR}
+Ci si può chiedere quale sia l'utilità di avere introdotto \const{SHUT\_RDWR}
 quando questa sembra rendere \funcd{shutdown} del tutto equivalente ad una
 \func{close}. In realtà non è così, esiste infatti un'altra differenza con
 \func{close}, più sottile. Finora infatti non ci siamo presi la briga di
@@ -3122,7 +3119,7 @@ dato che restano altri riferimenti attivi, uno al socket connesso nel figlio
 ed uno a quello in ascolto nel padre.
 
 Questo non avviene affatto se si usa \func{shutdown} con argomento
-\macro{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
+\const{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
 chiusura del socket viene effettuata immediatamente, indipendentemente dalla
 presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
 gli altri file descriptor con cui, nello stesso o in altri processi, si fa
@@ -3150,7 +3147,7 @@ velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
 una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
 vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
 di processo, questo tempo è quello impiegato nella trasmissione via rete, che
-viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time}
+viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time~(RTT)}
 \textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
 \cmd{ping}.
 
@@ -3177,9 +3174,9 @@ effettuerà la chiusura dalla sua parte. Solo alla ricezione della chiusura del
 socket da parte del server il client potrà essere sicuro della ricezione di
 tutti i dati e della terminazione effettiva della connessione.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ClientEcho.c}
   \end{minipage} 
   \normalsize
@@ -3255,9 +3252,8 @@ limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
 utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
 file descriptor attivi, operando direttamente su ciascuno di essi.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=13cm]{img/TCPechoMult}
+\begin{figure}[!htb]
+  \centering \includegraphics[width=13cm]{img/TCPechoMult}
   \caption{Schema del nuovo server echo basato sull'I/O multiplexing.}
   \label{fig:TCP_echo_multiplex}
 \end{figure}
@@ -3273,7 +3269,7 @@ disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/select_echod.c}
   \end{minipage} 
   \normalsize
@@ -3310,17 +3306,17 @@ con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket trovati
 attivi.
 
 Per far questo si usa la caratteristica dei file descriptor, descritta in
-sez.~\ref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file
-il file descriptor con il valore più basso disponibile. Questo fa sì che si
-possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo, che
-sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
-valore massimo di \var{max\_fd} che dovremo aver cura di tenere aggiornato.
-Dopo di che basterà controllare (\texttt{\small 9}) nella nostra tabella se il
-file descriptor è in uso o meno,\footnote{si tenga presente che benché il
-  kernel assegni sempre il primo valore libero, dato che nelle operazioni i
-  socket saranno aperti e chiusi in corrispondenza della creazione e
-  conclusione delle connessioni, si potranno sempre avere dei \textsl{buchi}
-  nella nostra tabella.} e impostare \var{fset} di conseguenza.
+sez.~\ref{sec:file_open_close}, per cui il kernel associa sempre ad ogni nuovo
+file il file descriptor con il valore più basso disponibile. Questo fa sì che
+si possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo,
+che sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd},
+fino al valore massimo di \var{max\_fd} che dovremo aver cura di tenere
+aggiornato.  Dopo di che basterà controllare (\texttt{\small 9}) nella nostra
+tabella se il file descriptor è in uso o meno,\footnote{si tenga presente che
+  benché il kernel assegni sempre il primo valore libero, dato che nelle
+  operazioni i socket saranno aperti e chiusi in corrispondenza della
+  creazione e conclusione delle connessioni, si potranno sempre avere dei
+  \textsl{buchi} nella nostra tabella.} e impostare \var{fset} di conseguenza.
 
 Una volta inizializzato con i socket aperti il nostro \textit{file descriptor
   set} potremo chiamare \func{select} per fargli osservare lo stato degli
@@ -3482,7 +3478,7 @@ ma la struttura del programma resta sostanzialmente la stessa.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/poll_echod.c}
   \end{minipage} 
   \normalsize
@@ -3584,7 +3580,7 @@ sez.~\ref{sec:TCP_serv_select}.
 
 
 
-\subsection{I/O multiplexing con \func{epoll}}
+\subsection{I/O multiplexing con \textit{epoll}}
 \label{sec:TCP_serv_epoll}
 
 Da fare.
@@ -3608,7 +3604,7 @@ Da fare.
 % LocalWords:  lsof SOCK sys int sockfd const struct sockaddr serv addr socklen
 % LocalWords:  addrlen errno EBADF descriptor EINVAL ENOTSOCK EACCES EADDRINUSE
 % LocalWords:  EADDRNOTAVAIL EFAULT ENOTDIR ENOENT ENOMEM ELOOP ENOSR EROFS RPC
-% LocalWords:  portmapper htonl tab endianess BROADCAST broadcast any extern fd
+% LocalWords:  portmapper htonl tab endianness BROADCAST broadcast any extern fd
 % LocalWords:  ADRR INIT DGRAM SEQPACKET servaddr ECONNREFUSED ETIMEDOUT EAGAIN
 % LocalWords:  ENETUNREACH EINPROGRESS EALREADY EAFNOSUPPORT EPERM EISCONN proc
 % LocalWords:  sysctl filesystem syn retries reset ICMP backlog EOPNOTSUPP RECV