X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=852e4a6bf16950054137ab481c0453a2b690060c;hp=ae53fd0d1dc7585b0451710636820d80484c0772;hb=5ae4c5191a8b2d6f9112c56d9e65dca942986fcf;hpb=fcd431ebcd9f7a65680a669a2740ef5a2586531c

diff --git a/tcpsock.tex b/tcpsock.tex
index ae53fd0..852e4a6 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -8,7 +8,7 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
-\chapter{Socket TCP}
+\chapter{Socket TCP elementari}
 \label{cha:TCP_socket}
 
 In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
@@ -365,7 +365,7 @@ durata di questo stato.
 
 Il primo dei due motivi precedenti si può capire tornando a
 \figref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
-(quello del capo che ha eseguito la chiusura attiva) vanga perso, chi esegue
+(quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue
 la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
 questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
 connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
@@ -1694,7 +1694,7 @@ scriverli su \file{stdout}.
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15.6cm}
-    \includecodesample{listati/ClientEcho.c}
+    \includecodesample{listati/ClientEcho_first.c}
   \end{minipage} 
   \normalsize
   \caption{Codice della prima versione della funzione \texttt{ClientEcho} per 
@@ -2082,8 +2082,8 @@ riscrittura parziale del server, la nuova versione di questo, in cui si sono
 introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
 mostrata in \figref{fig:TCP_echo_server_code_second}, dove si sono riportate
 la sezioni di codice modificate nella seconda versione del programma, il
-sorgente completo di quest'ultimo si trova nel file
-\file{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
+codice completo di quest'ultimo si trova nel file \file{TCP\_echod\_second.c}
+dei sorgenti allegati alla guida.
 
 La prima modifica effettuata è stata quella di introdurre una nuova opzione a
 riga di comando, \texttt{-c}, che permette di richiedere il comportamento
@@ -2237,7 +2237,7 @@ attraverso la sequenza vista in \secref{sec:TCP_conn_term}, per cui la
 al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
 modifichi il client per fargli gestire l'invio di un segmento di RST alla
 chiusura dal socket (come suggerito da Stevens in \cite{UNP1}), non si ha
-nessun errore al ritorno di \funcd{accept} quanto un errore di
+nessun errore al ritorno di \funcd{accept}, quanto un errore di
 \errcode{ECONNRESET} al primo tentativo di accesso al socket.
 
 
@@ -2430,7 +2430,7 @@ la nuova versione della funzione in \figref{fig:TCP_ClientEcho_second}.
   \end{minipage} 
   \normalsize
   \caption{La sezione nel codice della seconda versione della funzione
-    \func{CleintEcho} usata dal client per il servizio \textit{echo}
+    \func{ClientEcho} usata dal client per il servizio \textit{echo}
     modificata per tener conto degli eventuali errori.}
   \label{fig:TCP_ClientEcho_second}
 \end{figure}
@@ -2537,7 +2537,7 @@ successivo, per tentare di ristabilire la connessione.
 
 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 trovane in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
+si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
 in questo caso in particolare da \file{tcp\_retries2}. 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
@@ -2573,8 +2573,8 @@ Un altro errore possibile in questo tipo di situazione, che si pu
 quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
 riportato alla ricezione di un pacchetto ICMP di \textit{destination
   unreachable} da parte del router che individua l'interruzione della
-connessione. Di nuovo anche qui tutto dipende da chi è il meccanismo più
-veloce ad accorgersi del problema.
+connessione. Di nuovo anche qui il risultato finale dipende da quale è il
+meccanismo più veloce ad accorgersi del problema.
 
 Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
 un valore di tentativi più basso, possiamo evitare la scadenza della