+\subsection{La funzione \func{close}}
+\label{sec:TCP_func_close}
+
+La funzione standard Unix \func{close} (vedi \secref{sec:file_close}) che si
+usa sui file può essere usata con lo stesso effetto anche sui file descriptor
+associati ad un socket.
+
+L'azione di questa funzione quando applicata a socket è di marcarlo come
+chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
+descriptor non è più utilizzabile dal processo e non può essere usato come
+argomento per una \func{write} o una \func{read} (anche se l'altro capo della
+connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
+i dati che ha in coda prima di iniziare la sequenza di chiusura.
+
+Vedremo più avanti in \secref{sec:TCP_so_linger} come è possibile cambiare
+questo comportamento, e cosa deve essere fatto perché il processo possa
+assicurarsi che l'altro capo abbia ricevuto tutti i dati.
+
+Come per tutti i file descriptor anche per i socket viene mantenuto un numero
+di riferimenti, per cui se più di un processo ha lo stesso socket aperto
+l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
+fintanto che il numero di riferimenti non si annulla, questo si applica, come
+visto in \secref{sec:file_sharing}, sia ai file descriptor duplicati che a
+quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
+si aspetta in una qualunque applicazione client/server.
+
+Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
+descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
+\func{shutdown} su cui torneremo in seguito (vedi \secref{sec:xxx_shutdown}).
+
+
+
+\section{Un esempio elementare: il servizio \textit{daytime}}
+\label{sec:TCP_daytime_application}
+
+Avendo introdotto le funzioni di base per la gestione dei socket, potremo
+vedere in questa sezione un primo esempio di applicazione elementare che
+implementa il servizio \textit{daytime} su TCP, secondo quanto specificato
+dall'\href{http://www.ietf.org/rfc/rfc0867.txt}{RFC~867}. Prima di passare
+agli esempi del client e del server, inizieremo riesaminando con maggiori
+dettagli una peculiarità delle funzioni di I/O, già accennata in
+\secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
+particolarmente rilevante. Passeremo poi ad illustrare gli esempi
+dell'implementazione, sia dal lato client, che dal lato server, che si è
+realizzato sia in forma iterativa che concorrente.
+
+
+\subsection{Il comportamento delle funzioni di I/O}
+\label{sec:sock_io_behav}
+
+Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
+le funzioni di input/output non sempre hanno lo stesso comportamento che
+avrebbero con i normali file di dati (in particolare questo accade per i
+socket di tipo stream).
+
+Infatti con i socket è comune che funzioni come \func{read} o \func{write}
+possano restituire in input o scrivere in output un numero di byte minore di
+quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
+comportamento normale per l'I/O su file, ma con i normali file di dati il
+problema si avverte solo quando si incontra la fine del file. In generale non
+è così, e con i socket questo è particolarmente evidente.
+
+
+\begin{figure}[htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/FullRead.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{FullRead}, che legge esattamente \var{count} byte
+ da un file descriptor, iterando opportunamente le letture.}
+ \label{fig:sock_FullRead_code}
+\end{figure}
+
+Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
+fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
+byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
+sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
+\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
+\secref{sec:ipc_pipes}).
+
+Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
+definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
+lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
+ritornare solo dopo avere letto o scritto esattamente il numero di byte
+specificato; il sorgente è riportato rispettivamente in
+\figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
+disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
+\file{FullWrite.c}.
+
+\begin{figure}[htb]
+ \centering
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/FullWrite.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{FullWrite}, che scrive esattamente \var{count}
+ byte su un file descriptor, iterando opportunamente le scritture.}
+ \label{fig:sock_FullWrite_code}
+\end{figure}
+
+Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
+fino all'esaurimento del numero di byte richiesti, in caso di errore viene
+controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
+call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
+l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
+
+Nel caso della lettura, se il numero di byte letti è zero, significa che si è
+arrivati alla fine del file (per i socket questo significa in genere che
+l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
+pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
+
+
+\subsection{Il client \textit{daytime}}
+\label{sec:TCP_daytime_client}
+
+Il primo esempio di applicazione delle funzioni di base illustrate in
+precedenza è relativo alla creazione di un client elementare per il servizio
+\textit{daytime}, un servizio elementare, definito
+nell'\href{http://www.ietf.org/rfc/rfc0867.txt}{RFC~867}, che restituisce
+l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
+alla porta 13.
+
+In \figref{fig:TCP_daytime_client_code} è riportata la sezione principale del
+codice del nostro client. Il sorgente completo del programma
+(\file{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
+funzione per stampare un messaggio di aiuto) è allegato alla guida nella
+sezione dei codici sorgente e può essere compilato su una qualunque macchina
+GNU/Linux.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/TCP_daytime.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice di un client elementare per il servizio
+ \textit{daytime}.}
+ \label{fig:TCP_daytime_client_code}
+\end{figure}
+
+Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
+dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
+tutta la parte relativa al trattamento degli argomenti passati dalla linea di
+comando (effettuata con le apposite funzioni illustrate in
+\secref{sec:proc_opt_handling}).
+
+Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
+\const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
+\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.
+
+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
+il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
+inizializzare tutto a zero, per poi inserire il tipo di indirizzo
+(\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
+la funzione \func{htons} per convertire il formato dell'intero usato dal
+computer a quello usato nella rete, infine \texttt{\small 23--27} si può
+utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
+passato dalla linea di comando.
+
+A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
+socket creato in precedenza (\texttt{\small 29}) si può stabilire la
+connessione con il server. Per questo si deve utilizzare come secondo
+argomento la struttura preparata in precedenza con il relativo indirizzo; si
+noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
+Un valore di ritorno della funzione negativo implica il fallimento della
+connessione, nel qual caso si stampa un errore (\texttt{\small 30}) e si
+ritorna (\texttt{\small 31}).
+
+Completata con successo la connessione il passo successivo (\texttt{\small
+ 34--40}) è leggere la data dal socket; il protocollo prevede che il server
+invii sempre una stringa alfanumerica, il formato della stringa non è
+specificato dallo standard, per cui noi useremo il formato usato dalla
+funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
+qualcosa del tipo:
+\begin{verbatim}
+Wed Apr 4 00:53:00 2001\r\n
+\end{verbatim}
+questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read}
+in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
+ 35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
+ 36}) sullo standard output con l'uso di \func{fputs}.
+
+Come si è già spiegato in \secref{sec:sock_io_behav} la risposta dal socket
+potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
+caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte. Per
+questo nel caso generale non si può mai assumere che tutti i dati arrivino con
+una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
+in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
+uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
+minore di zero (che significa un errore nella connessione).
+
+Si noti come in questo caso la fine dei dati sia specificata dal server che
+chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
+è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
+ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
+di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
+mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
+punto essenziale è che TCP non provvede nessuna indicazione che permetta di
+marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
+programma stesso.
+
+Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
+ fornito direttamente dal \textsl{superdemone} \texttt{inetd}, pertanto basta
+ assicurarsi che esso sia abilitato nel relativo file di configurazione.}
+possiamo verificare il funzionamento del nostro client, avremo allora:
+\begin{verbatim}
+[piccardi@gont sources]$ ./daytime 127.0.0.1
+Mon Apr 21 20:46:11 2003
+\end{verbatim}%$
+e come si vede tutto funziona regolarmente.
+
+
+\subsection{Un server \textit{daytime} iterativo}
+\label{sec:TCP_daytime_iter_server}
+
+Dopo aver illustrato il client daremo anche un esempio di un server
+elementare, che sia anche in grado di rispondere al precedente client. Come
+primo esempio realizzeremo un server iterativo, in grado di fornire una sola
+risposta alla volta. Il codice del programma è nuovamente mostrato in
+\figref{fig:TCP_daytime_iter_server_code}, il sorgente completo
+(\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/TCP_iter_daytimed.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice di un semplice server per il servizio daytime.}
+ \label{fig:TCP_daytime_iter_server_code}
+\end{figure}
+
+Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
+cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
+ 14--18}) alcune costanti e le variabili necessarie in seguito. Come nel caso
+precedente si sono omesse le parti relative al trattamento delle opzioni da
+riga di comando.
+
+La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
+come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
+\struct{sockaddr\_in}. Anche in questo caso (\texttt{\small 28}) si usa la
+porta standard del servizio daytime, ma come indirizzo IP si usa
+(\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
+all'indirizzo generico.
+
+Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
+che permette di associare la precedente struttura al socket, in modo che
+quest'ultimo possa essere usato per accettare connessioni su una qualunque
+delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small
+ 31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
+programma.
+
+Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
+ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
+\func{listen} che dice al kernel di accettare connessioni per il socket che
+abbiamo creato; la funzione indica inoltre, con il secondo parametro, il
+numero massimo di connessioni che il kernel accetterà di mettere in coda per
+il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
+un messaggio, e si esce (\texttt{\small 38}) immediatamente.
+
+La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
+(che viene chiamato anche \textit{listening descriptor}) a questo punto si può
+procedere con il ciclo principale (\texttt{\small 40--53}) che viene eseguito
+indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
+connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
+caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
+(\texttt{\small 44}).
+
+Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
+accettata una connessione da un client; quando questo avviene \func{accept}
+ritorna, restituendo un secondo descrittore, che viene chiamato
+\textit{connected descriptor}, e che è quello che verrà usato dalla successiva
+chiamata alla \func{write} per scrivere la risposta al client.
+
+Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
+con una chiamata a \texttt{time}, con il quale si potrà opportunamente
+costruire (\texttt{\small 47}) la stringa con la data da trasmettere
+(\texttt{\small 48}) con la chiamata a \func{write}. Completata la
+trasmissione il nuovo socket viene chiuso (\texttt{\small 52}). A questo
+punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
+l'invio della data in risposta ad una successiva connessione.
+
+È importante notare che questo server è estremamente elementare, infatti, a
+parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
+di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
+\textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
+comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
+modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
+ ciclo principale.} per tener conto di quanto illustrato in
+\secref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma di
+gestione della terminazione del processo, dato che tutti i file descriptor
+vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
+non è necessario preoccuparsi di gestire la loro terminazione.
+
+
+\subsection{Un server \textit{daytime} concorrente}
+\label{sec:TCP_daytime_cunc_server}
+
+Il server \texttt{daytime} dell'esempio in
+\secref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
+in cui viene servita una richiesta alla volta; in generale però, specie se il
+servizio è più complesso e comporta uno scambio di dati più sostanzioso di
+quello in questione, non è opportuno bloccare un server nel servizio di un
+client per volta; per questo si ricorre alle capacità di multitasking del
+sistema.
+
+Come accennato anche in \secref{sec:proc_gen} una delle modalità più comuni di
+funzionamento da parte dei server è quella di usare la funzione \func{fork}
+per creare, ad ogni richiesta da parte di un client, un processo figlio che si
+incarichi della gestione della comunicazione. Si è allora riscritto il server
+\textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
+una opzione per la stampa degli indirizzi delle connessioni ricevute.
+
+In \figref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
+codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
+rimaste invariate rispetto al precedente esempio (cioè tutta la parte
+riguardante l'apertura passiva del socket). Al solito il sorgente completo del
+server, nel file \file{TCP\_cunc\_daytimed.c}, è allegato insieme ai sorgenti
+degli altri esempi.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/TCP_cunc_daytimed.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice di un server concorrente elementare per il
+ servizio daytime.}
+ \label{fig:TCP_daytime_cunc_server_code}
+\end{figure}
+
+Stavolta (\texttt{\small 21--25}) la funzione \func{accept} è chiamata
+fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
+la porta da cui il client effettua la connessione, che in un secondo tempo,
+(\texttt{\small 39--43}), se il logging è abilitato, stamperemo sullo standard
+output.
+
+Quando \func{accept} ritorna il server chiama la funzione \func{fork}
+(\texttt{\small 26--30}) per creare il processo figlio che effettuerà
+(\texttt{\small 31--45}) tutte le operazioni relative a quella connessione,
+mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
+ulteriori connessioni.
+
+Si noti come il figlio operi solo sul socket connesso, chiudendo
+immediatamente (\texttt{\small 32}) il socket \var{list\_fd}; mentre il padre
+continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 47})
+\var{sock\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
+\secref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
+l'innesco della sequenza di chiusura perché il numero di riferimenti al file
+descriptor non si è annullato.
+
+Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
+lo stesso vale per \var{sock\_fd} dopo il ritorno di \func{accept}, ma dopo la
+\func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
+entrambi i socket si trovano con due referenze. Questo fa si che quando il
+padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
+e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
+le sue operazioni, chiamerà (\texttt{\small 44}) la funzione \func{close}.
+
+In realtà per il figlio non sarebbe necessaria nessuna chiamata a
+\func{close}, in quanto con la \func{exit} finale (\texttt{\small 45}) tutti i
+file descriptor, quindi anche quelli associati ai socket, vengono
+automaticamente chiusi. Tuttavia si è preferito effettuare esplicitamente le
+chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali
+errori, prevenendo ad esempio un uso involontario del \textit{listening
+ descriptor}.
+
+Si noti invece come sia essenziale che il padre chiuda ogni volta il socket
+connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
+sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio
+resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
+padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato
+per ogni processo) e soprattutto nessuna delle connessioni con i client
+verrebbe chiusa.
+
+Come per ogni server iterativo il lavoro di risposta viene eseguito
+interamente dal processo figlio. Questo si incarica (\texttt{\small 33}) di
+chiamare \func{time} per leggere il tempo corrente, e di stamparlo
+(\texttt{\small 34}) sulla stringa contenuta in \var{buffer} con l'uso di
+\func{snprintf} e \func{ctime}. Poi la stringa viene scritta (\texttt{\small
+ 35--38}) sul socket, controllando che non ci siano errori. Anche in questo
+caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
+estremamente breve e verrà senz'altro scritta in un singolo segmento.
+
+Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
+provvede anche (\texttt{\small 39--42}) a stampare sullo standard output
+l'indirizzo e la porta da cui il client ha effettuato la connessione, usando
+i valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
+opportune conversioni con \func{inet\_ntop} e \func{atohs}.
+
+Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
+non si sia gestita né la terminazione del processo né il suo uso come demone,
+che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging
+che stampa gli indirizzi delle connessioni sullo standard output. Un altro
+aspetto tralasciato è la gestione della terminazione dei processi figli,
+torneremo su questo più avanti quando tratteremo alcuni esempi di server più
+complessi.
+
+
+
+\section{Un esempio più completo: il servizio \textit{echo}}
+\label{sec:TCP_echo_application}
+
+L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
+elementare, in cui il flusso dei dati va solo nella direzione dal server al
+client. In questa sezione esamineremo un esempio di applicazione client/server
+un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
+le direzioni.
+
+Ci limiteremo a fornire una implementazione elementare, che usi solo le
+funzioni di base viste finora, ma prenderemo in esame, oltre al comportamento
+in condizioni normali, anche tutti i possibili scenari particolari (errori,
+sconnessione della rete, crash del client o del server durante la connessione)
+che possono avere luogo durante l'impiego di un'applicazione di rete, partendo
+da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
+poter tenere conto di tutte le evenienze che si possono manifestare nella vita
+reale di un'applicazione di rete, fino ad arrivare ad un'implementazione
+completa.
+
+
+\subsection{Il servizio \textit{echo}}
+\label{sec:TCP_echo}
+
+
+Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
+bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
+usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
+immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
+servizio costituisce il prototipo ideale per una generica applicazione di rete
+in cui un server risponde alle richieste di un client. Nel caso di una
+applicazione più complessa quello che si potrà avere in più è una elaborazione
+dell'input del client, che in molti casi viene interpretato come un comando,
+da parte di un server che risponde fornendo altri dati in uscita.
+
+Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
+direttamente dal superserver \cmd{inetd}, ed è definito
+dall'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~862}. Come dice il nome il
+servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
+ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
+il primo stabilisce che una volta stabilita la connessione ogni dato in
+ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
+chiude la connessione. Al servizio è assegnata la porta riservata 7.
+
+Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
+caratteri dallo standard input e la scrive sul server. A sua volta il server
+leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
+compito del client leggere la risposta del server e stamparla sullo standard
+output.
+
+
+\subsection{Il client: prima versione}
+\label{sec:TCP_echo_client}
+
+Il codice della prima versione del client per il servizio \textit{echo},
+disponibile nel file \file{TCP\_echo1.c}, è riportato in
+\figref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
+client per il servizio \textit{daytime} (vedi
+\secref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) è
+sostanzialmente identica, a parte l'uso di una porta diversa.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6 cm}
+ \includecodesample{listati/TCP_echo1.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione del client \textit{echo}.}
+ \label{fig:TCP_echo_client_1}
+\end{figure}
+
+Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
+riga di comando. Una volta dichiarate le variabili, si prosegue
+(\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
+degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
+dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
+\textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
+specificato a riga di comando. A questo punto (\texttt{\small 23--27}) si può
+eseguire la connessione al server secondo la stessa modalità usata in
+\secref{sec:TCP_daytime_client}.
+
+Completata la connessione, per gestire il funzionamento del protocollo si usa
+la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
+\figref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
+comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
+scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
+risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche
+il programma termina.
+
+La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per
+gestire i dati inviati e letti sul socket. La comunicazione viene gestita
+all'interno di un ciclo (\texttt{\small 5--10}), i dati da inviare sulla
+connessione vengono presi dallo \file{stdin} usando la funzione \func{fgets},
+che legge una linea di testo (terminata da un \texttt{CR} e fino al massimo di
+\const{MAXLINE} caratteri) e la salva sul buffer di invio.
+
+Si usa poi (\texttt{\small 6}) la funzione \func{FullWrite}, vista in
+\secref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo
+automaticamente l'invio multiplo qualora una singola \func{write} non sia
+sufficiente. I dati vengono riletti indietro (\texttt{\small 7}) con una
+\func{FullRead} sul buffer di ricezione e viene inserita (\texttt{\small 8})
+la terminazione della stringa e per poter usare (\texttt{\small 9}) la
+funzione \func{fputs} per scriverli su \file{stdout}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/ClientEcho.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione della funzione \texttt{ClientEcho} per
+ la gestione del servizio \textit{echo}.}
+ \label{fig:TCP_client_echo_sub}
+\end{figure}
+
+Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
+input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
+quanto spiegato in \secref{sec:file_line_io}) e la conseguente uscita dal
+ciclo; al che la subroutine ritorna ed il nostro programma client termina.
+
+Si può effettuare una verifica del funzionamento del client abilitando il
+servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
+macchina ed usandolo direttamente verso di esso in locale, vedremo in
+dettaglio più avanti (in \secref{sec:TCP_echo_startup}) il funzionamento del
+programma, usato però con la nostra versione del server \textit{echo}, che
+illustriamo immediatamente.
+
+
+\subsection{Il server: prima versione}
+\label{sec:TCPsimp_server_main}
+
+La prima versione del server, contenuta nel file \file{TCP\_echod\_first.c}, è
+riportata in \figref{fig:TCP_echo_server_first_code}. Come abbiamo fatto per
+il client anche il server è stato diviso in un corpo principale, costituito
+dalla funzione \code{main}, che è molto simile a quello visto nel precedente
+esempio per il server del servizio \textit{daytime} di
+\secref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
+\code{ServEcho} che si cura della gestione del servizio.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/TCP_echod_first.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del corpo principale della prima versione del server
+ per il servizio \textit{echo}.}
+ \label{fig:TCP_echo_server_first_code}
+\end{figure}
+
+In questo caso però, rispetto a quanto visto nell'esempio di
+\figref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
+curando maggiormente alcuni dettagli, per tenere conto anche di alcune
+esigenze generali (che non riguardano direttamente la rete), come la
+possibilità di lanciare il server anche in modalità interattiva e la cessione
+dei privilegi di amministratore non appena questi non sono più necessari.
+
+La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
+server di \secref{sec:TCP_daytime_cunc_server}, ed ivi descritta in dettaglio:
+crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato che
+quest'ultima funzione viene usata su una porta riservata, il server dovrà
+essere eseguito da un processo con i privilegi di amministratore, pena il
+fallimento della chiamata.
+
+Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
+non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
+evitare problemi in caso di eventuali vulnerabilità del server. Per questo
+prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il
+processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
+ ovvero -1 per il formato \ctyp{short}, che di norma in tutte le
+ distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e
+ l'utente \texttt{nobody}, usati appunto per eseguire programmi che non
+ richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small
+ 27--30}) l'operazione usando \func{setuid} per cambiare anche
+l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
+ due operazioni è importante, infatti solo avendo i privilegi di
+ amministratore si può cambiare il gruppo di un processo ad un'altro di cui
+ non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
+ successiva chiamata a \func{setgid}. Inoltre si ricordi (si riveda quanto
+ esposto in \secref{sec:proc_perms}) che usando queste due funzioni il
+ rilascio dei privilegi è irreversibile.} Infine (\texttt{\small 30--36}),
+qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31})
+si apre il sistema di logging per la stampa degli errori, e poi
+(\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
+processo come demone.
+
+A questo punto il programma riprende di nuovo lo schema già visto usato dal
+server per il servizio \textit{daytime}, con l'unica differenza della chiamata
+alla funzione \code{PrintErr}, riportata in \figref{fig:TCP_PrintErr}, al
+posto di \func{perror} per la stampa degli errori.
+
+Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si
+esegue indefinitamente il ciclo principale (\texttt{\small 42--58}).
+All'interno di questo si ricevono (\texttt{\small 43--46}) le connessioni,
+creando (\texttt{\small 47--50}) un processo figlio per ciascuna di esse.
+Quest'ultimo (\texttt{\small 51--55}), chiuso (\texttt{\small 52}) il
+\textit{listening socket}, esegue (\texttt{\small 53}) la funzione di gestione
+del servizio \code{ServEcho}, ed al ritorno di questa (\texttt{\small 54})
+esce.
+
+Il padre invece si limita (\texttt{\small 56}) a chiudere il \textit{connected
+ socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
+questo modo si ha un server concorrente. La terminazione del padre non è
+gestita esplicitamente, e deve essere effettuata inviando un segnale al
+processo.
+
+Avendo trattato direttamente la gestione del programma come demone, si è
+dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
+errore attraverso il sistema del \textit{syslog} trattato in
+\secref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando come
+\textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato in
+\figref{fig:TCP_PrintErr}.
+
+In essa ci si limita a controllare se è stato impostato (valore attivo per
+default) l'uso come demone, nel qual caso (\texttt{\small 3}) si usa
+\func{syslog} per stampare il messaggio di errore fornito come argomento sui
+log di sistema. Se invece si è in modalità interattiva (attivabile con
+l'opzione \texttt{-i}) si usa semplicemente la funzione \func{perror} per
+stampare sullo standard error.
+
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/PrintErr.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della funzione \code{PrintErr} per la
+ generalizzazione della stampa degli errori sullo standard input o
+ attraverso il \texttt{syslog}.}
+ \label{fig:TCP_PrintErr}
+\end{figure}
+
+La gestione del servizio \textit{echo} viene effettuata interamente nella
+funzione \code{ServEcho}, il cui codice è mostrato in
+\figref{fig:TCP_ServEcho}, la comunicazione viene gestita all'interno del
+ciclo (\texttt{\small 6--8}). I dati inviati dal client vengono letti dal
+socket con una semplice \func{read} (che ritorna solo in presenza di dati in
+arrivo), la riscrittura viene invece gestita dalla funzione \func{FullWrite}
+(descritta in \figref{fig:sock_FullWrite_code}) che si incarica di tenere
+conto automaticamente della possibilità che non tutti i dati di cui è
+richiesta la scrittura vengano trasmessi con una singola \func{write}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/ServEcho.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione della funzione \code{ServEcho} per la
+ gestione del servizio \textit{echo}.}
+ \label{fig:TCP_ServEcho}
+\end{figure}
+
+Nella funzione si è anche inserita la possibilità (\texttt{\small 7--14}) di
+inviare dei messaggi di debug (abilitabile con l'uso dell'opzione \texttt{-d}
+che imposta opportunamente \var{debugging}), gestendo entrambi i casi in cui
+la stampa deve essere effettuata tramite \func{syslog} (\texttt{\small 11}) o
+direttamente sullo standard output (\texttt{\small 13}).
+
+Quando il client chiude la connessione il ricevimento del FIN fa ritornare la
+\func{read} con un numero di byte letti pari a zero, il che causa l'uscita dal
+ciclo e il ritorno della funzione, che a sua volta causa la terminazione del
+processo figlio.
+
+
+\subsection{L'avvio e il funzionamento normale}
+\label{sec:TCP_echo_startup}
+
+Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
+di considerare in dettaglio tutte le problematiche che si possono incontrare
+nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
+modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
+che avviene nelle varie situazioni limite, da una parte potremo approfondire
+la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
+necessarie per essere in grado di scrivere applicazioni robuste, in grado di
+gestire anche i casi limite.
+
+Il primo passo è compilare e lanciare il server (da root, per poter usare la
+porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
+la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
+si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
+stato con \cmd{netstat}:
+\begin{verbatim}
+[piccardi@roke piccardi]$ netstat -at
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+...
+tcp 0 0 *:echo *:* LISTEN
+...
+\end{verbatim} %$
+che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando
+connessioni da qualunque indirizzo e da qualunque porta e su qualunque
+interfaccia locale.
+
+A questo punto si può lanciare il client, esso chiamerà \func{socket} e
+\func{connect}; una volta completato il three way handshake la connessione è
+stabilita; la \func{connect} ritornerà nel client\footnote{si noti che è
+ sempre la \func{connect} del client a ritornare per prima, in quanto
+ questo avviene alla ricezione del secondo segmento (l'ACK del server) del
+ three way handshake, la \func{accept} del server ritorna solo dopo
+ un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene
+ ricevuto.} e la \func{accept} nel server, ed usando di nuovo
+\cmd{netstat} otterremmo che:
+\begin{verbatim}
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+tcp 0 0 *:echo *:* LISTEN
+tcp 0 0 roke:echo gont:32981 ESTABLISHED
+\end{verbatim}
+mentre per quanto riguarda l'esecuzione dei programmi avremo che:
+\begin{itemize}
+\item il client chiama la funzione \code{ClientEcho} che si blocca sulla
+ \func{fgets} dato che non si è ancora scritto nulla sul terminale.
+\item il server eseguirà una \func{fork} facendo chiamare al processo figlio
+ la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
+ dal socket sul quale ancora non sono presenti dati.
+\item il processo padre del server chiamerà di nuovo \func{accept}
+ bloccandosi fino all'arrivo di un'altra connessione.
+\end{itemize}
+e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
+un risultato del tipo:
+\begin{verbatim}
+[piccardi@roke piccardi]$ ps ax
+ PID TTY STAT TIME COMMAND
+ ... ... ... ... ...
+ 2356 pts/0 S 0:00 ./echod
+ 2358 pts/1 S 0:00 ./echo 127.0.0.1
+ 2359 pts/0 S 0:00 ./echod
+\end{verbatim} %$
+(dove si sono cancellate le righe inutili) da cui si evidenzia la presenza di
+tre processi, tutti in stato di \textit{sleep} (vedi
+\tabref{tab:proc_proc_states}).
+
+Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
+niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
+in \secref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
+\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
+poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
+a sua volta sarà inviato sullo standard output, che nel caso ne provoca
+l'immediatamente stampa a video.
+
+
+\subsection{La conclusione normale}
+\label{sec:TCP_echo_conclusion}
+
+Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
+ristampato a video fintanto che non concluderemo l'immissione dei dati; una
+sessione tipica sarà allora del tipo:
+\begin{verbatim}
+[piccardi@roke sources]$ ./echo 127.0.0.1
+Questa e` una prova
+Questa e` una prova
+Ho finito
+Ho finito
+\end{verbatim} %$
+che termineremo inviando un EOF dal terminale (usando la combinazione di tasti
+ctrl-D, che non compare a schermo); se eseguiamo un \cmd{netstat} a questo
+punto avremo:
+\begin{verbatim}
+[piccardi@roke piccardi]$ netstat -at
+tcp 0 0 *:echo *:* LISTEN
+tcp 0 0 localhost:33032 localhost:echo TIME_WAIT
+\end{verbatim} %$
+con il client che entra in \texttt{TIME\_WAIT}.
+
+Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
+terminazione normale della connessione, che ci servirà poi da riferimento
+quando affronteremo il comportamento in caso di conclusioni anomale:
+
+\begin{enumerate}
+\item inviando un carattere di EOF da terminale la \func{fgets} ritorna
+ restituendo un puntatore nullo che causa l'uscita dal ciclo di
+ \code{while}, così la \code{ClientEcho} ritorna.
+\item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
+ come parte del processo terminazione tutti i file descriptor vengono chiusi
+ (si ricordi quanto detto in \secref{sec:proc_term_conclusion}); questo causa
+ la chiusura del socket di comunicazione; il client allora invierà un FIN al
+ server a cui questo risponderà con un ACK. A questo punto il client verrà a
+ trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
+ \texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
+ \secref{sec:TCP_conn_term}).
+\item quando il server riceve il FIN la \func{read} del processo figlio che
+ gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
+ ciclo e il ritorno di \code{ServEcho}, a questo punto il processo figlio
+ termina chiamando \func{exit}.
+\item all'uscita del figlio tutti i file descriptor vengono chiusi, la
+ chiusura del socket connesso fa sì che venga effettuata la sequenza finale
+ di chiusura della connessione, viene emesso un FIN dal server che riceverà
+ un ACK dal client, a questo punto la connessione è conclusa e il client
+ resta nello stato \texttt{TIME\_WAIT}.
+\end{enumerate}
+
+
+\subsection{La gestione dei processi figli}
+\label{sec:TCP_child_hand}
+
+Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
+del procedimento di chiusura del processo figlio nel server (si veda quanto
+esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
+segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
+gestore e che l'azione predefinita per questo segnale è quella di essere
+ignorato, non avendo predisposto la ricezione dello stato di terminazione,
+otterremo che il processo figlio entrerà nello stato di zombie\index{zombie}
+(si riveda quanto illustrato in \secref{sec:sig_sigchld}), come risulterà
+ripetendo il comando \cmd{ps}:
+\begin{verbatim}
+ 2356 pts/0 S 0:00 ./echod
+ 2359 pts/0 Z 0:00 [echod <defunct>]
+\end{verbatim}
+
+Dato che non è il caso di lasciare processi zombie\index{zombie}, occorrerà
+ricevere opportunamente lo stato di terminazione del processo (si veda
+\secref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
+quanto illustrato in \secref{sec:sig_sigchld}. Una prima modifica al nostro
+server è pertanto quella di inserire la gestione della terminazione dei
+processi figli attraverso l'uso di un gestore. Per questo useremo la funzione
+\code{Signal} della nostra libreria personale, che abbiamo illustrato in
+\figref{fig:sig_Signal_code}, per installare il gestore che riceve i segnali
+dei processi figli terminati già visto in \figref{fig:sig_sigchld_handl}.
+Basterà allora aggiungere il seguente codice:
+\includecodesnip{listati/sigchildhand.c}
+\noindent
+all'esempio illustrato in \figref{fig:TCP_echo_server_first_code}.
+
+In questo modo però si introduce un altro problema, il fatto che, come
+spiegato in \secref{sec:sig_gen_beha}, quando un programma si trova in stato
+di \texttt{sleep} durante l'esecuzione di una system call, questa viene
+interrotta alla ricezione di un segnale, per cui alla fine dell'esecuzione del
+gestore il programma, se questo ritorna, l'esecuzione del programma riprenderà
+con l'uscita dalla system call con un errore di \errcode{EINTR}.
+
+Questo comporta che quando si chiude il client, con la terminazione del
+processo figlio, il padre, che riceve il segnale ed esegue il gestore,
+ritornerà dalla \func{accept} (a meno di un caso fortuito in cui il segnale
+arriva durante l'esecuzione del programma in risposta ad una connessione) con
+un errore di \errcode{EINTR}, terminando a sua volta con un errore del tipo:
+\begin{verbatim}
+[root@gont sources]# ./echod -i
+accept error: Interrupted system call
+\end{verbatim}%#
+
+
+Come accennato in \secref{sec:sig_gen_beha} questo ci mette di fronte a due
+possibili soluzioni, la più semplice è quella di modificare il codice di
+\func{Signal} per richiedere il riavvio automatico delle system call
+interrotte secondo la semantica di BSD, usando l'opzione \const{SA\_RESTART}
+di \func{sigaction}; rispetto a quanto visto in \figref{fig:sig_Signal_code}
+definiremo allora la nuova funzione \func{SignalRestart} come mostrato in
+\figref{fig:sig_SignalRestart_code}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/SignalRestart.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \funcd{SignalRestart}, che installa un gestore di
+ segnali in semantica BSD per il riavvio delle system call interrotte.}
+ \label{fig:sig_SignalRestart_code}
+\end{figure}
+
+Come si può notare questa funzione è identica a \func{Signal}, solo che in
+questo caso invece di inizializzare a zero il campo \var{sa\_flags} di
+\struct{sigaction}, lo si inizializza (\texttt{\small 5}) al valore
+\const{SA\_RESTART}. Usando questa funzione al posto di \func{Signal} nel
+server non è necessaria nessuna altra modifica: le system call interrotte
+saranno automaticamente riavviate, e l'errore \errcode{EINTR} non si
+manifesterà più.
+
+La seconda soluzione è più invasiva e richiede di controllare tutte le volte
+l'errore restituito dalle varie system call, ripetendo la chiamata qualora
+questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
+della portabilità, infatti lo standard POSIX dice che la funzionalità di
+riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
+opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
+Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
+ parte degli Unix derivati da BSD non fanno ripartire \func{select}, ed
+ alcuni non fanno ripartire neanche \func{accept} e \func{recvfrom}; nel caso
+ di Linux questa è disponibile.} anche quando questa è presente, non è detto
+possa essere usata con \func{accept}. La portabilità però viene al costo di
+una riscrittura parziale del server, secondo quanto mostrato in
+\figref{fig:TCP_echo_server_code}.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/TCP_echod.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del corpo principale della seconda versione del server
+ per il servizio \textit{echo}.}
+ \label{fig:TCP_echo_server_code}
+\end{figure}
+
+
+
+
+
+\section{I vari scenari critici}
+\label{sec:TCP_echo_critical}
+
+Con le modifiche viste in \secref{sec:TCP_child_hand} il nostro esempio
+diventa in grado di affrontare correttamente 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.
+
+