Altro lavoro sul server echo, e sulle condizioni particolari

[gapil.git] / elemtcp.tex

diff --git a/elemtcp.tex b/elemtcp.tex
index 585f6053803cc296a121b2e9fee9408a76ff069a..cfc4c8530540a00cd5f686f80614fbd13fbbdbf4 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -1328,7 +1328,7 @@ Il primo passo (\texttt{\small 14--18}) 
 \func{socket} ritorna il descrittore che viene usato per identificare il
 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
 stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
-(\texttt{\small 16}) con un codice di errore.
+(\texttt{\small 17}) con un codice di errore.
 
 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
@@ -2114,16 +2114,20 @@ la rete 
 gestire tutta una serie di situazioni critiche che non esistono per i processi
 locali.
 
-Come accennato in \secref{sec:TCP_func_accept} la funzione \func{accept}
-riporta tutti gli eventuali errori di rete pendenti su una connessione sul
-\textit{connected socket}; questo significa che, oltre al caso di interruzione
-da parte di un segnale, esistono altri errori non fatali che necessitano
-semplicemente la ripetizione della chiamata senza che si debba uscire dal
-programma. Un esempio possibile è quello mostrato in
-\figref{fig:TCP_early_abort}, in cui la connessione viene abortita dal client
-con l'invio di un segmento RST prima che sia stata chiamata la funzione
-\func{accept}.
-
+La prima situazione critica è quella della terminazione precoce, per via di un
+qualche errore di rete, della connessione effettuata da un client. Come
+accennato in \secref{sec:TCP_func_accept} la funzione \func{accept} riporta
+tutti gli eventuali errori di rete pendenti su una connessione sul
+\textit{connected socket}. 
+
+Questo significa che, oltre alla interruzione da parte di un segnale, che
+abbiamo trattato in \secref{sec:TCP_child_hand} nel caso particolare di
+\const{SIGCHLD}, si possono avere altri errori non fatali all'uscita di
+\func{accept}, che necessitano semplicemente la ripetizione della chiamata
+senza che si debba uscire dal programma. Uno scenario tipo è quello mostrato
+in \figref{fig:TCP_early_abort}, in cui la connessione viene abortita sul lato
+client con l'invio di un segmento RST, prima che nel server sia stata chiamata
+la funzione \func{accept}.
 
 \begin{figure}[htb]
   \centering
@@ -2132,6 +2136,30 @@ con l'invio di un segmento RST prima che sia stata chiamata la funzione
   \label{fig:TCP_early_abort}
 \end{figure}
 
+Benché questo non sia un fatto comune un evento simile può essere osservato
+con dei server molto occupati. In tal caso, in una struttura del server simile
+a quella del nostro esempio, in cui la gestione delle singole connessioni è
+demandata a processi figli, può accadere che il three way handshake venga
+completato e la relativa connessione abortita subito dopo, prima che il padre,
+per via del carico della macchina abbia fatto in tempo a rieseguire la
+chiamata \func{accept}. In questo caso si ha una situazione analoga a quella
+illustrata in \figref{fig:TCP_early_abort}, la connessione viene stabilita, ma
+subito dopo si ha una condizione 
+
+
+che, come nell'esempio in figura, ritornerebbe
+immediatamente con un errore relativo alla connessione abortita.
+
+
+Si tenga presente che questo tipo di terminazione non è riproducibile
+terminando il client prima della chiamata ad \func{accept}; in tal caso
+infatti il socket associato alla connessione viene semplicemente chiuso,
+attraverso la sequenza vista in \secref{sec:TCP_conn_term}, per cui la
+\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
+al primo accesso al socket.
+
+In questo caso 
+
 
 
 %%% Local Variables: