+
+\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\_echo\_first.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_echo_first.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{read}\footnote{si è fatta l'assunzione implicita che i dati siano
+ contenuti tutti in un solo segmento, così che la chiamata a \texttt{read} li
+ restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer
+ questo sarà sempre vero, vedremo più avanti come superare il problema di
+ rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} 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 (\texttt{\small 2}) se è stato impostato
+(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
+ 3}) si usa \func{syslog} (vedi \secref{sec:sess_daemon}) 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
+(\texttt{\small 5}) 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_first}, e la comunicazione viene gestita all'interno
+di un ciclo (\texttt{\small 6--13}). I dati inviati dal client vengono letti
+(\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
+controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
+in arrivo. La riscrittura (\texttt{\small 7}) 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_first.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione della funzione \code{ServEcho} per la
+ gestione del servizio \textit{echo}.}
+ \label{fig:TCP_ServEcho_first}
+\end{figure}
+
+In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
+valore nullo in caso di successo) si provvede (\texttt{\small 8--10}) a
+stampare il relativo messaggio con \func{PrintErr}. 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
+(\texttt{\small 12}) 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 le varie 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 funzione \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} (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. Si ricordi infatti 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 questo motivo, alla fine
+dell'esecuzione del gestore del segnale, se questo ritorna, il programma
+riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
+di \errcode{EINTR}.
+
+Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
+client, il processo figlio che gestisce la connessione terminerà, ed il padre,
+per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
+eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
+padre ripartirà subito con il ritorno della funzione \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}. Non avendo
+previsto questa eventualità il programma considera questo un errore fatale
+terminando a sua volta con un messaggio del tipo:
+\begin{verbatim}
+[root@gont sources]# ./echod -i
+accept error: Interrupted system call
+\end{verbatim}%#
+
+Come accennato in \secref{sec:sig_gen_beha} le conseguenze di questo
+comportamento delle system call possono essere superate in due modi diversi,
+il più semplice è quello 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}\footnote{anche questa è definita, insieme
+ alle altre funzioni riguardanti la gestione dei segnali, nel file
+ \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
+ allegati.} come mostrato in \figref{fig:sig_SignalRestart_code}, ed
+installeremo il gestore usando quest'ultima.
+
+\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 automatico delle system call
+ interrotte.}
+ \label{fig:sig_SignalRestart_code}
+\end{figure}
+
+Come si può notare questa funzione è identica alla precedente \func{Signal},
+illustrata in \figref{fig:sig_Signal_code}, 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}; altri
+ non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
+ caso di Linux viene sempre fatta.} anche quando questa è presente, non è
+detto possa essere usata con \func{accept}.
+
+
+La portabilità nella gestione dei segnali però viene al costo di una
+riscrittura parziale del server, la nuova versione di questo, in cui si sono
+introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
+mostrata in \figref{fig:TCP_echo_server_code_second}, dove si sono riportate
+la sezioni di codice modificate nella seconda versione del programma, il
+sorgente completo di quest'ultimo si trova nel file
+\file{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
+
+La prima modifica effettuata è stata quella di introdurre una nuova opzione a
+riga di comando, \texttt{-c}, che permette di richiedere il comportamento
+compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
+impostando la variabile \var{compat} ad un valore non nullo. Questa è
+preimpostata al valore nullo, cosicché se non si usa questa opzione il
+comportamento di default del server è di usare la semantica BSD.
+
+Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
+specificato in secondi fra il ritorno della funzione \func{listen} e la
+chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
+permette di impostare la variabile \var{waiting}. Infine si è introdotta una
+opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
+nullo la variabile \var{debugging}. Al solito si è omessa da
+\figref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
+gestione di tutte queste opzioni, che può essere trovata nel sorgente del
+programma.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/TCP_echod_second.c}
+ \end{minipage}
+ \normalsize
+ \caption{La sezione nel codice della seconda versione del server
+ per il servizio \textit{echo} modificata per tener conto dell'interruzione
+ delle system call.}
+ \label{fig:TCP_echo_server_code_second}
+\end{figure}
+
+Vediamo allora come è cambiato il nostro server; una volta definite le
+variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
+verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
+del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
+funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
+(\texttt{\small 12}), essendo quest'ultimo il valore di default.
+
+Tutta la sezione seguente, che crea il socket, cede i privilegi di
+amministratore ed eventualmente lancia il programma come demone, è rimasta
+invariata e pertanto è stata omessa in
+\figref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima
+dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
+dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una
+eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
+\var{waiting}, che viene inizializzata, con l'opzione \code{-w Nsec}, al
+numero di secondi da aspettare (il valore preimpostato è nullo).
+
+Si è potuto lasciare inalterata tutta la sezione di creazione del socket
+perché nel server l'unica chiamata ad una system call critica, che può essere
+interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
+l'unica funzione che può mettere il processo padre in stato di sleep nel
+periodo in cui un figlio può terminare; si noti infatti come le altre
+\textit{slow system call}\footnote{si ricordi la distinzione fatta in
+ \secref{sec:sig_gen_beha}.} o sono chiamate prima di entrare nel ciclo
+principale, quando ancora non esistono processi figli, o sono chiamate dai
+figli stessi e non risentono di \const{SIGCHLD}.
+
+Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
+ 23--42}), rispetto precedente versione di \figref{fig:TCP_ServEcho_first}, è
+nella sezione (\texttt{\small 26--30}) in cui si effettua la chiamata di
+\func{accept}. Quest'ultima viene effettuata (\texttt{\small 26--27})
+all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
+ questo ciclo può non essere del tutto chiara. In questo caso infatti si è
+ usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
+ quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
+ condizione all'interno del \code{while}.} che la ripete indefinitamente
+qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
+altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
+altrimenti il programma prosegue.
+
+Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
+(\texttt{\small 31--39}) di aiuto per il debug del programma, che eseguita con
+un controllo (\texttt{\small 31}) sul valore della variabile \var{debugging}
+impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
+preimpostato, non accade nulla. altrimenti (\texttt{\small 32}) l'indirizzo
+ricevuto da \var{accept} viene convertito in una stringa che poi
+(\texttt{\small 33--38}) viene opportunamente stampata o sullo schermo o nei
+log.
+
+
+
+
+\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 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.
+
+
+\subsection{La terminazione precoce della connessione}
+\label{sec:TCP_conn_early_abort}
+
+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, 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.
+
+È 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 per un qualche errore di rete 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, 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 ad
+eseguire 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
+\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. In Linux
+i possibili errori di rete non fatali, riportati sul socket connesso al
+ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
+\errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
+\errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
+
+Si tenga presente che questo tipo di terminazione non è riproducibile
+terminando il client prima della chiamata ad \func{accept}, come si potrebbe
+fare usando l'opzione \texttt{-w} per introdurre una pausa dopo il lancio del
+demone, in modo da poter avere il tempo per lanciare e terminare una
+connessione usando il programma client. In tal caso infatti, alla terminazione
+del client, 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. Nel caso di Linux inoltre, anche qualora si
+modifichi il client per fargli gestire l'invio di un segmento di RST alla
+chiusura dal socket (come suggerito da Stevens in \cite{UNP1}), non si ha
+nessun errore al ritorno di \funcd{accept} quanto un errore di
+\errcode{ECONNRESET} al primo tentativo di accesso al socket.
+
+
+
+\subsection{Il crollo del server}
+\label{sec:TCP_server_crash}
+
+Un secondo caso critico è quello in cui si ha il crollo del server. In tal
+caso si suppone che il processo del server termini per un errore fatale, cosa
+che potremo simulare inviandogli un segnale di terminazione. La conclusione
+del processo comporta la chiusura di tutti i file aperti, compresi tutti i
+socket relativi a connessioni stabilite; questo significa che al momento del
+crollo del servizio il client riceverà un FIN dal server in corrispondenza
+della chiusura del socket.
+
+
+
+
+