+che come si vede il traffico fra client e server si interrompe dopo l'invio di
+un pacchetto UDP per il quale non si è ricevuto risposta.
+
+Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
+una richiesta non arriva a destinazione, il nostro programma si bloccherà
+nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
+in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
+pacchetti, il risultato è diverso, se si lancia al solito il programma e si
+prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
+se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
+\begin{verbatim}
+[root@gont gapil]# tcpdump \( dst 192.168.0.2 and src 192.168.1.120 \) \
+ or \( src 192.168.0.2 and dst 192.168.1.120 \)
+tcpdump: listening on eth0
+00:43:27.606944 gont.earthsea.ea.32789 > 192.168.1.120.echo: udp 6 (DF)
+00:43:27.990560 192.168.1.120 > gont.earthsea.ea: icmp: 192.168.1.120 udp port
+echo unreachable [tos 0xc0]
+\end{verbatim}
+cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
+irraggiungibile che ci segnala che la porta in questione non risponde.
+
+Ci si può chiedere allora perché, benché la situazione di errore sia
+rilevabile, questa non venga segnalata. Il luogo più naturale in cui
+riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
+di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
+questo punto però è impossibile, dato che l'interfaccia di programmazione
+richiede che la funzione ritorni non appena il kernel invia il
+pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
+ una situazione cioè in cui la condizione di errore viene rilevata in maniera
+ asincrona rispetto all'operazione che l'ha causata, una eventualità
+ piuttosto comune quando si ha a che fare con la rete, tutti i pacchetti ICMP
+ che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
+una attesa di una risposta che potrebbe essere molto lunga (si noti infatti
+che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
+esserci affatto.
+
+Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
+comunque bloccata in attesa di una risposta che nel caso non arriverà mai. La
+ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
+Stevens in \cite{UNP2} con il seguente esempio: si consideri un client che
+invia tre pacchetti a tre diverse macchine, due dei quali vengono regolarmente
+ricevuti, mentre al terzo, non essendo presente un server sulla relativa
+macchina, viene risposto con un messaggio ICMP come il precedente. Detto
+messaggio conterrà anche le informazioni relative ad indirizzo e porta del
+pacchetto che ha fallito, però tutto quello che il kernel può restituire al
+programma è un codice di errore in \var{errno}, con il quale è impossibile di
+distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
+stata fatta la scelta di non riportare un errore su un socket UDP, a meno che,
+come vedremo in sez.~\ref{sec:UDP_connect}, questo non sia connesso.