X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=3a64aa794a8231c7b467cd7e6b536805f533df06;hp=5af4f66259967f04ceb680c55a227e08fcd8680e;hb=a0184b68ca9dced41be95342ffd8a8ee04d2b861;hpb=9eb4436b75582594619576d54f28073ba027111a

diff --git a/othersock.tex b/othersock.tex
index 5af4f66..3a64aa7 100644
--- a/othersock.tex
+++ b/othersock.tex
@@ -13,7 +13,7 @@
 
 Dopo aver trattato in \capref{cha:TCP_socket} i socket TCP, che costituiscono
 l'esempio più comune dell'interfaccia dei socket, esamineremo in questo
-capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket deiit
+capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
 \textit{Unix domain} già incontrati in \secref{sec:ipc_socketpair}.
 
 
@@ -477,6 +477,102 @@ 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}[!htb] 
+  \footnotesize \centering
+  \begin{minipage}[c]{15.6cm}
+    \includecodesample{listati/UDP_echo.c}
+  \end{minipage} 
+  \normalsize
+  \caption{Sezione principale del client per il servizio \textit{echo} su
+    UDP.}
+  \label{fig:UDP_echo_client}
+\end{figure}
+
+In \figref{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 \figref{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}[!htb] 
+  \footnotesize \centering
+  \begin{minipage}[c]{15.6cm}
+    \includecodesample{listati/UDP_ClientEcho.c}
+  \end{minipage}
+  \normalsize
+  \caption{Codice della funzione \func{ClientEcho} usata dal client per il
+    servizio \textit{echo} su UDP.}
+  \label{fig:UDP_echo_clientecho}
+\end{figure}
+
+Ovviamente in questo caso il funzionamento della funzione, il cui codice è
+riportato in \figref{fig:UDP_echo_clientecho}, è completamente diverso
+rispetto alla analoga del server TCP, e dato che non esiste una connessione
+questa necessita anche di un terzo parametro, che è l'indirizzo del server cui
+inviare i pacchetti.
+
+Data l'assenza della connessione 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}) di una stringa dallo standard input
+
+
+
+
+
+In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
+problema, se però si prova ad eseguirlo attraverso un collegamento remoto (nel
+caso 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
+
+\end{verbatim}%$
+si otterrà che dopo aver correttamente stampato alcune righe il programma si
+bloccherà completamente senza stampare più niente. Se al contempo si fosse
+tenuto sotto controllo il traffico UDP con \cmd{tcpdump} si sarebbe ottenuto:
+\begin{verbatim}
+[root@gont gapil]# tcpdump  \( dst port 7 or src port 7 \)
+...
+...
+18:48:16.390255 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
+18:48:17.177613 192.168.1.120.echo > gont.earthsea.ea.32788: udp 4 (DF)
+18:48:17.177790 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 26 (DF)
+18:48:17.964917 192.168.1.120.echo > gont.earthsea.ea.32788: udp 26 (DF)
+18:48:17.965408 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
+\end{verbatim}
+che come si vede termina con l'invio di un pacchetto UDP per il quale non si è
+ricevuto risposta.
+
 
 
 \subsection{L'uso della funzione \func{connect} con i socket UDP}