Aggiunta sezione sullo stato sul server

[gapil.git] / tcpsock.tex

diff --git a/tcpsock.tex b/tcpsock.tex
index 20f143ea39dd8ed8dfef6e3f818cbd0d3aa2f32b..4c411cda92de4e63aa72b15961219094db18587d 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -2348,9 +2348,19 @@ descriptor, il che comporta, per il socket che avevamo aperto, l'inizio della
 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)
@@ -2359,6 +2369,8 @@ Proto Recv-Q Send-Q Local Address           Foreign Address         State
 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