sequenza di chiusura illustrata in \secref{sec:TCP_conn_term}. Questo
significa che dal server partirà un FIN, che è appunto il primo dei due
pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
-ACK da parte del client. A questo punto la connessione dalla parte del server
-è chiusa, ed infatti se usiamo \cmd{netstat} per controllarne lo stato sul
-client, otterremo che essa è andata nello stato \texttt{CLOSE\_WAIT}:
+ACK da parte del client.
+
+A questo punto la connessione dalla parte del server è chiusa, ed infatti se
+usiamo \cmd{netstat} per controllarne lo stato sul server otteremo che:
+\begin{verbatim}
+anarres:/home/piccardi# netstat -ant
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+... ... ... ... ... ...
+tcp 0 0 192.168.1.141:7 192.168.1.2:34626 FIN_WAIT2
+\end{verbatim}
+cioè, come aspettato, essa è nello stato \texttt{FIN_WAIT2}, mentre sul client
+otterremo che essa è andata nello stato \texttt{CLOSE\_WAIT}:
\begin{verbatim}
[root@gont gapil]# netstat -ant
Active Internet connections (servers and established)
tcp 1 0 192.168.1.2:34582 192.168.1.141:7 CLOSE_WAIT
\end{verbatim}
+
+
Il problema è che in questo momento il client è bloccato dentro la funzione
\texttt{ClientEcho} nella chiamata a \func{fgets}, e sta attendendo dell'input
dal terminale, per cui non è in grado di accorgersi di nulla. Solo quando