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.
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
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