+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}
+
+In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
+del nostro client elementare per il servizio \textit{echo} (al solito il
+codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
+client visto in fig.~\ref{fig:TCP_echo_client_1} sono che al solito si crea
+(\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
+presente nessuna chiamata a \func{connect}. Per il resto il funzionamento del
+programma è identico, e tutto il lavoro viene effettuato attraverso la
+chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
+però prende un argomento in più, che è l'indirizzo del socket.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/UDP_ClientEcho_first.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della funzione \func{ClientEcho} usata dal client per il
+ servizio \textit{echo} su UDP.}
+ \label{fig:UDP_echo_client_echo}
+\end{figure}
+
+Ovviamente in questo caso il funzionamento della funzione, il cui codice è
+riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
+rispetto alla analoga del server TCP, e dato che non esiste una connessione
+questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
+inviare i pacchetti.
+
+Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
+più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
+ 6--30}) che parte dalla lettura (\texttt{\small 7}) sul buffer di invio
+\var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
+(\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
+immediatamente causando anche la susseguente terminazione del programma.
+
+Altrimenti si procede (\texttt{\small 10--11}) all'invio della stringa al
+destinatario invocando \func{sendto}, utilizzando, oltre alla stringa appena
+letta, gli argomenti passati nella chiamata a \func{ClientEcho}, ed in
+particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
+(\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
+(\texttt{\small 13--14}) ad uscire con un messaggio di errore.
+
+Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
+leggere l'eventuale risposta del server con \func{recvfrom}; si noti come in
+questo caso si sia scelto di ignorare l'indirizzo dell'eventuale pacchetto di
+risposta, controllando (\texttt{\small 18--21}) soltanto la presenza di un
+errore (nel qual caso al solito si ritorna dopo la stampa di un adeguato
+messaggio). Si noti anche come, rispetto all'analoga funzione
+\func{ClientEcho} utilizzata nel client TCP illustrato in
+sez.~\ref{sec:TCP_echo_client} non si sia controllato il caso di un messaggio
+nullo, dato che, nel caso di socket UDP, questo non significa la terminazione
+della comunicazione.
+
+L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
+stringa di risposta nel relativo buffer per poi provvedere alla sua stampa
+sullo standard output, eseguendo il solito controllo (ed eventuale uscita con
+adeguato messaggio informativo) in caso di errore.
+
+In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
+problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
+(nel caso dell'esempio seguente su una VPN, attraverso una ADSL abbastanza
+congestionata) e in modalità non interattiva, la probabilità di perdere
+qualche pacchetto aumenta, ed infatti, eseguendo il comando come:
+\begin{verbatim}
+[piccardi@gont sources]$ cat UDP_echo.c | ./echo 192.168.1.120
+/* UDP_echo.c
+ *
+ * Copyright (C) 2004 Simone Piccardi
+...
+...
+/*
+ * Include needed headers