+diventa in grado di affrontare la gestione ordinaria delle connessioni, ma un
+server di rete deve tenere conto che, al contrario di quanto avviene per i
+server che operano nei confronti di processi presenti sulla stessa macchina,
+la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
+gestire tutta una serie di situazioni critiche che non esistono per i processi
+locali.
+
+La prima situazione critica è quella della terminazione precoce, causata da un
+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.
+
+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}.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/tcp_client_early_abort}
+ \caption{Un possibile caso di terminazione precoce della connessione.}
+ \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.
+
+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 ricevere altri errori non fatali all'uscita di
+\func{accept}, che come nel caso precedente, necessitano semplicemente la
+ripetizione della chiamata senza che si debba uscire dal programma. In questo
+caso anche la versione modificata del nostro server non sarebbe adatta, in
+quanto uno di questi errori causerebbe la terminazione dello stesso.
+
+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. Per riprodurre l'errore occorrerebbe usare
+l'opzione \const{SO\_LINGER} (vedi \secref{sec:xxx}) per chiedere al client di
+chiudere il socket con un segmento RST, invece che con la normale sequenza di
+chiusura.
+