X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=da47e6f41c67c805320f56734fa6f261581015a6;hp=344ee30446e847d2afd67dc216b752566d34b163;hb=d44259cffb0d41ed62ec80f7d653bd7606894866;hpb=374461977afeaf3ec285f3d4f0f1d3b47f7e4043

diff --git a/tcpsock.tex b/tcpsock.tex
index 344ee30..da47e6f 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -355,7 +355,7 @@ comune trovare domande su come sia possibile evitare che un'applicazione resti
 in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
 che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
 
-\itindex{Maximum~Segment~Lifetime}
+\itindbeg{Maximum~Segment~Lifetime~(MSL)}
 Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
 \texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
 esegue la chiusura attiva resta prima di passare alla chiusura definitiva
@@ -374,6 +374,7 @@ router; quando si annulla il pacchetto viene scartato.  Siccome il numero è ad
 TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
 sua base si può stimare che un pacchetto IP non possa restare nella rete per
 più un certo numero di secondi, che costituisce la MSL.
+\itindend{Maximum~Segment~Lifetime~(MSL)}
 
 Ogni realizzazione del TCP deve scegliere un valore per la MSL;
 l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
@@ -1682,7 +1683,7 @@ descriptor non si è annullato.
 Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
 lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
 \func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
-entrambi i socket si trovano con due referenze. Questo fa si che quando il
+entrambi i socket si trovano con due referenze. Questo fa sì che quando il
 padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
 e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
 le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
@@ -1780,8 +1781,8 @@ stamparla sullo \textit{standard output}.
 \subsection{Il client \textit{echo}: prima versione}
 \label{sec:TCP_echo_client}
 
-Il codice della prima versione del client per il servizio \textit{echo},
-disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
+Il codice della prima versione del client per il servizio \textit{echo} (file
+\texttt{TCP\_echo\_first.c}) dei sorgenti allegati alla guida) è riportato in
 fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
 client per il servizio \textit{daytime} (vedi
 sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
@@ -2958,7 +2959,7 @@ pronto per la scrittura sono le seguenti:
   errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
 \end{itemize*}
 
-Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
+Infine c'è una sola condizione che fa sì che \func{select} ritorni segnalando
 che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
 condizione di eccezione pendente, e cioè la ricezione sul socket di
 \textsl{dati urgenti} (o \textit{out-of-band}), una caratteristica specifica
@@ -2975,7 +2976,7 @@ Lo scopo dei due valori di soglia per i buffer di ricezione e di invio è
 quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
 dei programmi, se infatti si sa che una applicazione non è in grado di fare
 niente fintanto che non può ricevere o inviare una certa quantità di dati, si
-possono utilizzare questi valori per far si che \func{select} ritorni solo
+possono utilizzare questi valori per far sì che \func{select} ritorni solo
 quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
   controllo è utile di norma solo per la lettura, in quanto in genere le
   operazioni di scrittura sono già controllate dall'applicazione, che sa