+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 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, 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 non arriverà mai.
+La ragione di tutto questo è piuttosto sottile e viene trattata da Stevens in
+\cite{UNP2} con il seguente esempio: si consideri un client che invia tre
+pacchetti a tre diverse macchine, due 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}, e pertanto è stata fatta la scelta di non
+riportare l'errore, a meno che, come vedremo in sez.~\ref{sec:UDP_connect}, il
+socket non sia connesso.