X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=elemtcp.tex;fp=elemtcp.tex;h=c2a9dbba7dbc1191407a2609b55df7e60af09ed9;hp=788fc169533773f412ca0214390271c4133e6bc0;hb=ab2e702bd899e2d99c70a90de1bb45ad62561e4e;hpb=12b230ea57ff3a54a12d4e2226e3901a2345fb63

diff --git a/elemtcp.tex b/elemtcp.tex
index 788fc16..c2a9dbb 100644
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -1,6 +1,6 @@
 %% elemtcp.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
@@ -2126,14 +2126,15 @@ La prima situazione critica 
 qualche errore sulla 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}. Di norma questo non è un problema a questo livello,
-in quanto una volta completata la connessione \func{accept} ritorna e l'errore
-sarà rilevato in seguito dal processo che la gestisce.
+\textit{connected socket}. Di norma questo non è un problema, in quanto non
+appena completata la connessione, \func{accept} ritorna e l'errore sarà
+rilevato in seguito dal processo che gestisce la connessione alla prima
+chiamata di una funzione che opera sul socket..
 
-In generale però è possibile incorrere anche in uno scenario del tipo di
-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}. 
+È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
+del tipo di 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
@@ -2142,16 +2143,16 @@ sia stata chiamata la funzione \func{accept}.
   \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}. Di nuovo si ha una situazione analoga a quella
-illustrata in \figref{fig:TCP_early_abort}, in cui la connessione viene
-stabilita, ma subito dopo si ha una condizione di errore che la chiude prima
-che essa sia stata accettata dal programma.
+Benché questo non sia un fatto comune, un evento simile può essere osservato
+con dei server molto occupati. In tal caso, con 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 ad \func{accept}. Di nuovo si ha una situazione analoga
+a quella illustrata in \figref{fig:TCP_early_abort}, in cui la connessione
+viene stabilita, ma subito dopo si ha una condizione di errore che la chiude
+prima che essa sia stata accettata dal programma.
 
 Questo significa che, oltre alla interruzione da parte di un segnale, che
 abbiamo trattato in \secref{sec:TCP_child_hand} nel caso particolare di