+o di tipo \textit{stream}) i byte in eccesso che non sono stati letti possono
+rispettivamente andare persi o restare disponibili per una lettura successiva.
+Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
+il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
+\errcode{EAGAIN}. Qualora \param{len} ecceda la dimensione del pacchetto la
+funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
+comunque il numero di byte letti.
+
+I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
+l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
+opportunamente inizializzati; il primo deve contenere il puntatore alla
+struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
+puntatore alla variabile con la dimensione di detta struttura. Si tenga
+presente che mentre il contenuto della struttura \ctyp{sockaddr} cui punta
+\param{from} può essere qualunque, la variabile puntata da \param{fromlen}
+deve essere opportunamente inizializzata a \code{sizeof(sockaddr)},
+assicurandosi che la dimensione sia sufficiente a contenere tutti i dati
+dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
+ serve ad indicare la struttura corrispondente allo specifico tipo di
+ indirizzo richiesto, il valore di \param{fromlen} pone un limite alla
+ quantità di dati che verranno scritti sulla struttura puntata da
+ \param{from} e se è insufficiente l'indirizzo risulterà corrotto.} Al
+ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
+lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
+\textit{value result argument}). Se non si è interessati a questa
+informazione, entrambi gli argomenti devono essere inizializzati al valore
+\val{NULL}.
+
+Una differenza fondamentale del comportamento di queste funzioni rispetto alle
+usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
+questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
+vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
+specificando un valore nullo per \param{len}. Allo stesso modo è possibile
+ricevere con \func{recvfrom} un valore di ritorno di 0 byte, senza che questo
+possa configurarsi come una chiusura della connessione\footnote{dato che la
+ connessione non esiste, non ha senso parlare di chiusura della connessione,
+ questo significa anche che con i socket UDP non è necessario usare
+ \func{close} o \func{shutdown} per terminare la comunicazione.} o come una
+cessazione delle comunicazioni.
+
+
+
+\subsection{Un client UDP elementare}
+\label{sec:UDP_daytime_client}
+
+Vediamo allora come implementare un primo client elementare con dei socket
+UDP. Ricalcando quanto fatto nel caso dei socket TCP prenderemo come primo
+esempio l'uso del servizio \textit{daytime}, utilizzando questa volta UDP. Il
+servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
+che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
+UDP al server (di contenuto non specificato), il quale risponderà a inviando a
+sua volta un pacchetto UDP contenente la data.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/UDP_daytime.c}
+ \end{minipage}
+ \normalsize
+ \caption{Sezione principale del client per il servizio \textit{daytime} su
+ UDP.}
+ \label{fig:UDP_daytime_client}
+\end{figure}
+
+In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
+codice del nostro client, il sorgente completo si trova nel file
+\file{UDP\_daytime.c} distribuito con gli esempi allegati alla guida; al
+solito si è tralasciato di riportare in figura la sezione relativa alla
+gestione delle opzioni a riga di comando (nel caso praticamente assenti).
+
+Il programma inizia (\texttt{\small 9--12}) con la creazione del socket, al
+solito uscendo dopo aver stampato un messaggio in caso errore. Si noti come in
+questo caso, rispetto all'analogo client basato su socket TCP di
+fig.~\ref{fig:TCP_daytime_client_code} si sia usato per il tipo di socket il
+valore \const{SOCK\_DGRAM}, pur mantenendosi nella stessa famiglia data da
+\const{AF\_INET}.
+
+Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
+struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
+completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
+la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
+(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare
+dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
+Si noti come questa sezione sia identica a quella del client TCP di
+fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
+di UDP al posto di TCP è stata effettuata quando si è creato il socket.
+
+Una volta completate le inizializzazioni inizia il corpo principale del
+programma, il primo passo è inviare, come richiesto dal protocollo, un
+pacchetto al server. Questo lo si fa (\texttt{\small 16}) inviando un
+pacchetto vuoto (si ricordi quanto detto in
+sez.~\ref{sec:UDP_sendto_recvfrom}) con \func{sendto}, avendo cura di passare
+un valore nullo per il puntatore al buffer e la lunghezza del messaggio. In
+realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
+server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
+
+Verificato (\texttt{\small 24--27}) che non ci siano stati errori nell'invio
+si provvede (\texttt{\small 28}) ad invocare \func{recvfrom} per ricevere la
+risposta del server. Si controlla poi (\texttt{\small 29--32}) che non vi
+siano stati errori in ricezione (uscendo con un messaggio in caso contrario);
+se è tutto a posto la variabile \var{nread} conterrà la dimensione del
+messaggio di risposta inviato dal server che è stato memorizzato su
+\var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
+provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
+lettura\footnote{si ricordi che, come illustrato in
+ sez.~\ref{sec:TCP_daytime_client}, il server invia in risposta una stringa
+ contenente la data, terminata dai due caratteri CR e LF, che pertanto prima
+ di essere stampata deve essere opportunamente terminata con un NUL.} e a
+stamparla (\texttt{\small 36}) sullo standard output, controllando anche in
+questo caso (\texttt{\small 36--38}) l'esito dell'operazione, ed uscendo con
+un messaggio in caso di errore.
+
+Se pertanto si è avuto cura di attivare il server del servizio
+\textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
+ \textsl{superdemone} \cmd{inetd}, per cui basta abilitarlo nel file di
+ configurazione di quest'ultimo, avendo cura di predisporre il servizio su
+ UDP.} potremo verificare il funzionamento del nostro client interrogando
+quest'ultimo con:
+\begin{verbatim}
+[piccardi@gont sources]$ ./daytime 127.0.0.1
+Sat Mar 20 23:17:13 2004
+\end{verbatim}%$
+ed osservando il traffico con uno sniffer potremo effettivamente vedere lo
+scambio dei due pacchetti, quello vuoto di richiesta, e la risposta del
+server:
+\begin{verbatim}
+[root@gont gapil]# tcpdump -i lo
+tcpdump: listening on lo
+23:41:21.645579 localhost.32780 > localhost.daytime: udp 0 (DF)
+23:41:21.645710 localhost.daytime > localhost.32780: udp 26 (DF)
+\end{verbatim}
+
+Una differenza fondamentale del nostro client è che in questo caso, non
+disponendo di una connessione, è per lui impossibile riconoscere errori di
+invio relativi alla rete. La funzione \func{sendto} infatti riporta solo
+errori locali, i dati vengono comunque scritti e la funzione ritorna senza
+errori anche se il server non è raggiungibile o non esiste un server in
+ascolto sull'indirizzo di destinazione. Questo comporta ad esempio che se si
+usa il nostro programma interrogando un server inesistente questo resterà
+perennemente bloccato nella chiamata a \func{recvfrom}, fin quando non lo
+interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
+a questa problematica.
+
+
+\subsection{Un server UDP elementare}
+\label{sec:UDP_daytime_server}
+
+Nella sezione precedente abbiamo visto come scrivere un client elementare per
+servizio \textit{daytime}, vediamo in questa come deve essere scritto un
+server. Si ricordi che il compito di quest'ultimo è quello di ricevere un
+pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
+stringa con la data corrente.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/UDP_daytimed.c}
+ \end{minipage}
+ \normalsize
+ \caption{Sezione principale del server per il servizio \textit{daytime} su
+ UDP.}
+ \label{fig:UDP_daytime_server}
+\end{figure}
+
+In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
+codice del nostro client, il sorgente completo si trova nel file
+\file{UDP\_daytimed.c} distribuito con gli esempi allegati alla guida; anche
+in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
+riga di comando (la sola presente è \texttt{-v} che permette di stampare a
+video l'indirizzo associato ad ogni richiesta).
+
+Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
+sostanzialmente identica a quella dell'analogo server per TCP illustrato in
+fig.~\ref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10})
+con il creare il socket, uscendo con un messaggio in caso di errore
+(\texttt{\small 10--13}), e di nuovo la sola differenza con il caso precedente
+è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
+si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
+usata da \func{bind}; si cancella (\texttt{\small 15}) preventivamente il
+contenuto, si imposta (\texttt{\small 16}) la famiglia dell'indirizzo, la
+porta (\texttt{\small 17}) e l'indirizzo (\texttt{\small 18}) su cui si
+riceveranno i pacchetti. Si noti come in quest'ultimo sia l'indirizzo
+generico \const{INADDR\_ANY}; questo significa (si ricordi quanto illustrato
+in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
+qualunque degli indirizzi presenti sulle interfacce di rete della macchina.
+
+Completata l'inizializzazione tutto quello che resta da fare è eseguire
+(\texttt{\small 20--23}) la chiamata a \func{bind}, controllando la presenza
+di eventuali errori, ed uscendo con un avviso qualora questo fosse il caso.
+Nel caso di socket UDP questo è tutto quello che serve per consentire al
+server di ricevere i pacchetti a lui indirizzati, e non è più necessario
+chiamare successivamente \func{listen}. In questo caso infatti non esiste il
+concetto di connessione, e quindi non deve essere predisposta una coda delle
+connessioni entranti. Nel caso di UDP i pacchetti arrivano al kernel con un
+certo indirizzo ed una certa porta di destinazione, il kernel controlla se
+corrispondono ad un socket che è stato \textsl{legato} ad essi con
+\func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
+socket, così che il programma possa leggerlo, altrimenti risponderà alla
+macchina che ha inviato il pacchetto con un messaggio ICMP di tipo
+\textit{port unreachable}.
+
+Una volta completata la fase di inizializzazione inizia il corpo principale
+(\texttt{\small 24--44}) del server, mantenuto all'interno di un ciclo
+infinito in cui si trattano le richieste. Il ciclo inizia (\texttt{\small 26})
+con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
+inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
+volte che un pacchetto viene inviato al server, in modo da poter ricavare da
+esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
+questo motivo in questo caso (al contrario di quanto fatto in
+fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
+\var{addr} e \var{len} alla funzione. Dopo aver controllato (\texttt{\small
+ 27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
+qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
+l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
+caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
+richiesta (questa sezione è identica a quella del server TCP illustrato in
+fig.~\ref{fig:TCP_daytime_cunc_server_code}).
+
+Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
+(\texttt{\small 36}) e costruire (\texttt{\small 37}) la stringa di risposta,
+che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
+avendo al solito cura di controllare (\texttt{\small 40--42}) lo stato di
+uscita della funzione e trattando opportunamente la condizione di errore.
+
+Si noti come per le peculiarità del protocollo si sia utilizzato un server
+iterativo, che processa le richieste una alla volta via via che gli arrivano.
+Questa è una caratteristica comune dei server UDP, conseguenza diretta del
+fatto che non esiste il concetto di connessione, per cui non c'è la necessità
+di trattare separatamente le singole connessioni. Questo significa anche che è
+il kernel a gestire la possibilità di richieste multiple in contemporanea;
+quello che succede è semplicemente che il kernel accumula in un buffer in
+ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
+volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
+compito del server distribuire le risposte sulla base dell'indirizzo da cui
+provengono le richieste.
+
+
+\subsection{Le problematiche dei socket UDP}
+\label{sec:UDP_problems}
+
+L'esempio del servizio \textit{daytime} illustrato nelle precedenti sezioni
+è in realtà piuttosto particolare, e non evidenzia quali possono essere i
+problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
+connessione che sono tipiche dei socket UDP. In tal caso infatti il protocollo
+è estremamente semplice, dato che la comunicazione consiste sempre in una
+richiesta seguita da una risposta, per uno scambio di dati effettuabile con un
+singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
+complessi da rilevare.
+
+Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
+la risposta del server si perdono, il client resterà permanentemente bloccato
+nella chiamata a \func{recvfrom}. Per evidenziare meglio quali problemi si
+possono avere proviamo allora con un servizio leggermente più complesso come
+\textit{echo}.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/UDP_echo_first.c}
+ \end{minipage}
+ \normalsize
+ \caption{Sezione principale della prima versione client per il servizio
+ \textit{echo} su UDP.}
+ \label{fig:UDP_echo_client}
+\end{figure}