+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/ElemDaytimeTCPClient.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice di un client elementare per il servizio daytime.}
+ \label{fig:TCP_cli_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
+\capref{sec:proc_opt_handling}).
+
+Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} TCP
+(quindi di famiglia \const{AF\_INET} e di tipo \const{SOCK\_STREAM}). 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 protocollo
+(\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 di 26 caratteri, nella forma giorno
+della settimana, mese, ora minuto e secondo, anno, seguita dai caratteri di
+teminazione \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 primo esempio di server}
+\label{sec:TCP_serv_sample}
+
+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_serv_code}, il sorgente completo
+(\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file degli
+esempi.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/ElemDaytimeTCPServer.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice di un semplice server per il servizio daytime.}
+ \label{fig:TCP_serv_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
+ad un 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 creatp; 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 (\texttt{\small 40--53}) principale che viene eseguito
+indefinitamente. Il primo passo è porsi (\texttt{\small 42}) 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 provesso resterà in stato di \textit{sleep} fin quando non arriva e viene
+accettata una connessione da un client; quando questo avviene \func{accept}
+ritorna un secondo descrittore di socket, 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 esso è 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 esempio di server \textit{daytime} concorrente}
+\label{sec:TCP_cunc_daytime}
+
+Il server \texttt{daytime} dell'esempio in \secref{sec:TCP_cli_sample} è 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 già visto per i server basati sui meccanismi di intercomunicazione locale
+visti in \capref{cha:IPC}, il modo più immediato per creare un server
+concorrente è quello 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 \texttt{daytime}
+dell'esempio precedente in forma concorrente, inserendo anche una opzione per
+la stampa degli indirizzi delle connessioni ricevute.
+
+In \figref{fig:TCP_cunc_serv_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
+\file{ElemDaytimeTCPCuncServ.c} è allegato insieme ai sorgenti degli altri
+esempi.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/ElemDaytimeTCPCuncServ.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice di un server concorrente elementare per il
+ servizio daytime.}
+ \label{fig:TCP_cunc_serv_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 più avanti
+(\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 resterà 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 \var{sock\_fd} dopo
+(\texttt{\small 47}) ciascuna \func{accept}. Per quanto abbiamo detto in
+\secref{sec:TCP_func_close} queste due chiusure non causano 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
+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à la funzione \func{close}.
+
+In realtà per il figlio non sarebbero necessarie nessuna delle due chiamate a
+\func{close} in quanto nella \func{exit} tutti i file ed i socket vengono
+chiusi. Tuttavia si è preferito effettuare la chiusura esplicitamente per
+avere una maggiore chiarezza del codice ed evitare possibili errori.
+
+Si noti come sia essenziale che il padre chiuda ogni volta il socket connesso
+dopo la \func{accept}; se così non fosse nessuno di questi socket sarebbe
+effettivamente chiuso dato che alla chiusura da parte del figlio resterebbe
+ancora un riferimento. 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.
+
+Si noti come anche in questo caso non si sia gestita né la terminazione del
+processo né il suo uso come demone, che tra l'altro sarenne 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.
+
+
+\subsection{Le funzioni \func{getsockname} e \func{getpeername}}
+\label{sec:TCP_get_names}
+
+Queste due funzioni vengono usate per ottenere i dati relativi alla socket
+pair associata ad un certo socket; la prima è \funcd{getsockname} e
+restituisce l'indirizzo locale; il suo prototipo è:
+\begin{prototype}{sys/socket.h}
+ {int getsockname(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
+ Legge l'indirizzo locale del socket \param{sockfd} nella struttura
+ \param{name}.
+
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore. I codici di errore restituiti in \var{errno} sono i seguenti:
+ \begin{errlist}
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ valido.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
+ eseguire l'operazione.
+ \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
+ spazio di indirizzi del processo.
+ \end{errlist}}
+\end{prototype}
+
+La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
+socket; ad esempio può essere usata da un client (che usualmente non chiama
+\func{bind}) per ottenere numero IP e porta locale associati al socket
+restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
+su un socket usando 0 come porta locale per ottenere il numero di porta
+effimera assegnato dal kernel.
+
+Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se
+chiamata dopo il completamento di una connessione sul socket restituito da
+\func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a
+quella connessione.
+
+Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
+funzione \funcd{getpeername}, il cui prototipo è:
+\begin{prototype}{sys/socket.h}
+ {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
+ Legge l'indirizzo remoto del socket \param{sockfd} nella struttura
+ \param{name}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore. I codici di errore restituiti in \var{errno} sono i seguenti:
+ \begin{errlist}
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ valido.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{ENOTCONN}] il socket non è connesso.
+ \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
+ eseguire l'operazione.
+ \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
+ spazio di indirizzi del processo.
+ \end{errlist}}
+\end{prototype}
+
+Ci si può chiedere a cosa serva questa funzione dato che dal lato client
+l'indirizzo remoto è sempre noto quando si esegue la \func{connect} mentre
+dal lato server si possono usare, come si è fatto nell'esempio precedente, i
+valori di ritorno di \func{accept}.
+
+In generale però questa ultima possibilità è sempre possibile. In particolare
+questo avviene quando il server invece di far gestire la connessione
+direttamente a un processo figlio, come nell'esempio precedente, lancia un
+opportuno programma per ciascuna connessione usando \func{exec} (questa ad
+esempio è la modalità con cui opera il \textsl{super-server} \cmd{inetd}
+che gestisce tutta una serie di servizi lanciando per ogni connessione
+l'opportuno server).
+
+In questo caso benché il processo figlio abbia una immagine della memoria che
+è copia di quella del processo padre (e contiene quindi anche la struttura
+ritornata da \func{accept}), all'esecuzione di \func{exec} viene caricata
+in memoria l'immagine del programma eseguito che a questo punto perde ogni
+riferimento. Il socket descriptor però resta aperto. Allora se una opportuna
+convenzione è seguita per rendere noto al programma eseguito qual'è il socket
+connesso (\cmd{inetd} ad esempio fa sempre in modo che i file descriptor 0,
+1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione
+\func{getpeername} per determinare l'indirizzo remoto del client.
+
+Infine è da chiarire (si legga la pagina di manuale) che, come per
+\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
+come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
+\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
+socket BSD fanno questa assunzione.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: