From: Simone Piccardi Date: Sun, 2 May 2004 13:10:32 +0000 (+0000) Subject: Completato echo su UDP, e messi cenni sulla connect per UDP, da riprendere X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=ec40bdfb4408819c4b6845e2c25b897ae505cc59;p=gapil.git Completato echo su UDP, e messi cenni sulla connect per UDP, da riprendere in seguito. Spostato il capitolo della gestione dei socket prima di quello sui socket UDP (almeno per ora) e iniziato a scrivere qualcosa sulla risoluzione dei nomi --- diff --git a/gapil.tex b/gapil.tex index 1d15abe..251237e 100644 --- a/gapil.tex +++ b/gapil.tex @@ -148,8 +148,8 @@ \include{network} \include{socket} \include{tcpsock} -\include{othersock} \include{sockctrl} +\include{othersock} \include{sockadv} \appendix \part{Appendici} diff --git a/listati/UDP_ClientEcho.c b/listati/UDP_ClientEcho.c index 746d5a7..3cbd3da 100644 --- a/listati/UDP_ClientEcho.c +++ b/listati/UDP_ClientEcho.c @@ -19,9 +19,6 @@ void ClientEcho(FILE * filein, int socket, struct sockaddr_in * serv_addr) printf("Errore in lettura: %s\n", strerror(errno)); return; } - if (nread == 0) { /* server closed connection, stop */ - return; - } recvbuff[nread] = 0; /* else read is ok, write on stdout */ if (fputs(recvbuff, stdout) == EOF) { perror("Errore in scrittura su terminale"); diff --git a/othersock.tex b/othersock.tex index 3a64aa7..7897c6e 100644 --- a/othersock.tex +++ b/othersock.tex @@ -11,7 +11,7 @@ \chapter{Gli altri tipi di socket} \label{cha:other_socket} -Dopo aver trattato in \capref{cha:TCP_socket} i socket TCP, che costituiscono +Dopo aver trattato in cap.~\ref{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 \textit{Unix domain} già incontrati in \secref{sec:ipc_socketpair}. @@ -29,10 +29,10 @@ principali e le modalit \subsection{Le caratteristiche di un socket UDP} \label{sec:UDP_characteristics} -Come illustrato in \secref{sec:net_udp} UDP è un protocollo molto semplice che +Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che non supporta le connessioni e non è affidabile: esso si appoggia direttamente -sopra IP (per i dettagli sul protocollo si veda \secref{sec:udp_protocol}). I -dati vengono inviati in forma di pacchetti, e non ne è assicurata né la +sopra IP (per i dettagli sul protocollo si veda sez.~\ref{sec:udp_protocol}). +I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il vantaggio del protocollo è la velocità, non è necessario trasmettere le informazioni di controllo ed il risultato è una trasmissione di dati più @@ -48,16 +48,16 @@ Questo diverso comportamento significa anche che i socket UDP, pur appartenendo alla famiglia \const{PF\_INET}\footnote{o \const{PF\_INET6} qualora si usasse invece il protocollo IPv6, che pure supporta UDP.} devono essere aperti quando si usa la funzione \func{socket} (si riveda quanto -illustrato a suo tempo in \tabref{tab:sock_sock_valid_combinations}) +illustrato a suo tempo in tab.~\ref{tab:sock_sock_valid_combinations}) utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}. Questa differenza comporta ovviamente che anche le modalità con cui si usano i socket UDP sono completamente diverse rispetto ai socket TCP, ed in particolare non esistendo il concetto di connessione non esiste il meccanismo -del \textit{three way handshake} nè quello degli stati del protocollo. In +del \textit{three way handshake} né quello degli stati del protocollo. In realtà tutto quello che avviene nella comunicazione attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un server o viceversa, -secondo lo schema illustrato in \figref{fig:UDP_packet-exchange}. +secondo lo schema illustrato in fig.~\ref{fig:UDP_packet-exchange}. \begin{figure}[htb] \centering @@ -67,17 +67,17 @@ secondo lo schema illustrato in \figref{fig:UDP_packet-exchange}. \label{fig:UDP_packet-exchange} \end{figure} -Come illustrato in \figref{fig:UDP_packet-exchange} la struttura generica di +Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di un server UDP prevede, una volta creato il socket, la chiamata a \func{bind} per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server TCP: non essendovi il concetto di connessione le funzioni \func{listen} ed \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una -eventuale risposta sarà inviata con la funzione \func{sendto}. +eventuale risposta sarà inviata con la funzione \func{sendto}. Da parte del client invece, una volta creato il socket non sarà necessario connettersi con \func{connect} (anche se, come vedremo in -\secref{sec:UDP_connect}, è possibile usare questa funzione, con un +sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un significato comunque diverso) ma si potrà effettuare direttamente una richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà leggere una eventuale risposta con la funzione \func{recvfrom}. @@ -113,19 +113,19 @@ destinati, oppure a scartarli inviando un messaggio \textit{ICMP port \subsection{Le funzioni \func{sendto} e \func{recvfrom}} \label{sec:UDP_sendto_recvfrom} -Come accennato in \secref{sec:UDP_characteristics} le due funzioni principali -usate per la trasmissione di dati attraverso i socket UDP sono \func{sendto} e -\func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che -non esistendo con UDP il concetto di connessione, non si ha neanche a -disposizione un \textsl{socket connesso} su cui sia possibile usare -direttamente \func{read} e \func{write} avendo già stabilito (grazie alla -chiamata ad \func{accept} che lo associa ad una connessione) quali sono +Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni +principali usate per la trasmissione di dati attraverso i socket UDP sono +\func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è +dovuta al fatto che non esistendo con UDP il concetto di connessione, non si +ha neanche a disposizione un \textsl{socket connesso} su cui sia possibile +usare direttamente \func{read} e \func{write} avendo già stabilito (grazie +alla chiamata ad \func{accept} che lo associa ad una connessione) quali sono sorgente e destinazione dei dati. Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due funzioni, che sono comunque utilizzabili in generale per la trasmissione di dati attraverso qualunque tipo di socket. Esse hanno la caratteristica di -prevedere tre argomenti aggiuntivi attraveso i quali è possibile specificare +prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le @@ -149,9 +149,9 @@ prima di queste funzioni rispettivo codice di errore: \begin{errlist} \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma - l'operazione richede che la funzione si blocchi. + l'operazione richiede che la funzione si blocchi. \item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la - conessione. + connessione. \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è specificato un indirizzo di destinazione. \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un @@ -189,9 +189,9 @@ fallisce con l'errore di \errcode{EMSGSIZE}. I due argomenti \param{to} e \param{tolen} servono a specificare la destinazione del messaggio da inviare, e indicano rispettivamente la struttura -contentente l'indirizzo di quest'ultima e la sua dimensione; questi argomenti +contenente l'indirizzo di quest'ultima e la sua dimensione; questi argomenti vanno specificati stessa forma in cui li si sarebbero usati con -\func{connect}. Nel nostro caso \param{to} devrà puntare alla struttura +\func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura contenente l'indirizzo IP e la porta di destinazione verso cui si vogliono inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando socket diversi si sarebbero dovute utilizzare le rispettive strutture degli @@ -201,8 +201,8 @@ Se il socket TCP), questo deve essere già connesso prima di poter eseguire la funzione, in caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono -essi devranno essere inizializzati rispettivamente a \const{NULL} e 0; -normalmente quando si opera su un socket conesso essi vengono ignorati, ma +essi dovranno essere inizializzati rispettivamente a \const{NULL} e 0; +normalmente quando si opera su un socket connesso essi vengono ignorati, ma qualora si sia specificato un indirizzo è possibile ricevere un errore di \errcode{EISCONN}. @@ -211,9 +211,9 @@ come maschera binaria che permette di impostare una serie di modalit funzionamento della comunicazione attraverso il socket (come \const{MSG\_NOSIGNAL} che impedisce l'invio del segnale \const{SIGPIPE} quando si è già chiuso il capo locale della connessione). Torneremo con maggiori -dettagli sul significato di questo argomento in \secref{sec:xxx_sendmsg}, dove -tratteremo le funzioni avanzate dei socket, per il momento ci si può limitare -ad usare sempre un valore nullo. +dettagli sul significato di questo argomento in sez.~\ref{sec:xxx_sendmsg}, +dove tratteremo le funzioni avanzate dei socket, per il momento ci si può +limitare ad usare sempre un valore nullo. La seconda funzione utilizzata nella comunicazione fra socket UDP è \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il @@ -237,7 +237,7 @@ suo prototipo\footnote{il prototipo valore: \begin{errlist} \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma - l'operazione richede che la funzione si blocchi, oppure si è impostato un + l'operazione richiede che la funzione si blocchi, oppure si è impostato un timeout in ricezione e questo è scaduto. \item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato la connessione (in genere perché il relativo servizio non è disponibile). @@ -265,7 +265,7 @@ l'indirizzo del mittente del pacchetto che opportunamente inizializzati con i puntatori alle variabili dove la struttura contenente quest'ultimo e la relativa lunghezza saranno scritti (si noti che \param{fromlen} è un valore intero ottenuto come \textit{value return - argoment}). Se non si è interessati a questa informazione, entrambi gli + argument}). Se non si è interessati a questa informazione, entrambi gli argomenti devono essere inizializzati al valore \const{NULL}. Una differenza fondamentale del comportamento di queste funzioni rispetto alle @@ -277,7 +277,7 @@ 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 cominicazione.} o come una + \func{close} o \func{shutdown} per terminare la comunicazione.} o come una cessazione delle comunicazioni. @@ -304,7 +304,7 @@ sua volta un pacchetto UDP contenente la data. \label{fig:UDP_daytime_client} \end{figure} -In \figref{fig:UDP_daytime_client} è riportato la sezione principale del +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 @@ -313,9 +313,9 @@ 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 -\figref{fig:TCP_daytime_client_code} si sia usato per il tipo di socket il +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}. +\const{AF\_INET}. Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della struttura degli indirizzi; prima (\texttt{\small 14}) si cancella @@ -324,17 +324,17 @@ la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine (\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare dal parametro passato a riga di comando, convertendolo con \func{inet\_pton}. Si noti come questa sezione sia identica a quella del client TCP di -\figref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso di -UDP al posto di TCP è stata effettuata quando si è creato il socket. +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 \secref{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. +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 @@ -345,8 +345,8 @@ messaggio di risposta inviato dal server che \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 - \secref{sec:TCP_daytime_client}, il server invia in risposta una stringa - contenente la data, terminata dai due carratteri CR e LF, che pertanto prima + 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 @@ -380,7 +380,7 @@ errori anche se il server non 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 \secref{sec:UDP_connect} come si può porre rimedio +interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio a questa problematica. @@ -404,7 +404,7 @@ stringa con la data corrente. \label{fig:UDP_daytime_server} \end{figure} -In \figref{fig:UDP_daytime_server} è riportato la sezione principale del +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 @@ -413,8 +413,8 @@ 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 -\figref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10}) con -il creare il socket, uscendo con un messaggio in caso di errore +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à @@ -423,7 +423,7 @@ 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 \secref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno +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 @@ -449,14 +449,14 @@ inviati dai client. Lo scopo della funzione 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 -\figref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti +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 -\figref{fig:TCP_daytime_cunc_server_code}). +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, @@ -506,14 +506,14 @@ possono avere proviamo allora con un servizio leggermente pi \label{fig:UDP_echo_client} \end{figure} -In \figref{fig:UDP_echo_client} è riportato un estratto del corpo principale +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 \figref{fig:TCP_echo_client_1} sono che al solito si crea +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 +chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta però prende un argomento in più, che è l'indirizzo del socket. \begin{figure}[!htb] @@ -528,24 +528,46 @@ per \end{figure} Ovviamente in questo caso il funzionamento della funzione, il cui codice è -riportato in \figref{fig:UDP_echo_clientecho}, è completamente diverso +riportato in fig.~\ref{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 +questa necessita anche di un terzo argomento, 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 - - - - +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 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: +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 @@ -557,9 +579,10 @@ eseguendo il comando come: * 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: +si otterrà che, dopo aver correttamente stampato alcune righe, il programma si +blocca completamente senza stampare più niente. Se al contempo si fosse tenuto +sotto controllo il traffico UDP diretto o proveniente dal servizio +\textit{echo} con \cmd{tcpdump} si sarebbe ottenuto: \begin{verbatim} [root@gont gapil]# tcpdump \( dst port 7 or src port 7 \) ... @@ -570,17 +593,58 @@ tenuto sotto controllo il traffico UDP con \cmd{tcpdump} si sarebbe ottenuto: 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. +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. \subsection{L'uso della funzione \func{connect} con i socket UDP} \label{sec:UDP_connect} -Come illustrato in \secref{sec:UDP_characteristics} essendo i socket UDP privi -di connessione non è necessario per i client usare \func{connect} prima di -iniziare una comunicazione con un server. +Come illustrato in sez.~\ref{sec:UDP_characteristics} essendo i socket UDP +privi di connessione non è necessario per i client usare \func{connect} prima +di iniziare una comunicazione con un server. @@ -593,6 +657,16 @@ macchina, li tratteremo comunque in questa sezione in quanto la loro interfaccia è comunque basata sulla più generale interfaccia dei socket. +\section{Altri socket} +\label{sec:socket_other} + + +Tratteremo in questa sezione gli altri tipi particolari di socket supportati +da Linux, come i \textit{raw socket}, con i quali si possono \textsl{forgiare} +direttamente i pacchetti a tutti i livelli dello stack dei protocolli, o i +socket \textit{netlink} che definiscono una interfaccia di comunicazione con +il kernel. + diff --git a/sockctrl.tex b/sockctrl.tex index 100d7cd..66015ac 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -11,17 +11,29 @@ \chapter{La gestione dei socket} \label{cha:sock_generic_management} -Esamineremo in questo capitolo le funzionalità più evolute della gestione dei -socket TCP, come l'uso del I/O multiplexing (trattato in -\secref{sec:file_multiplexing}) con i socket, l'uso delle opzioni dei socket e -la gestione dei dati urgenti e \textit{out-of-band}. - +Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative +alla gestione dei socket, come la gestione della risoluzione di nomi e +indirizzi, le impostazioni delle varie proprietà degli stessi, e le funzioni +di controllo che vanno ad operare su di essi. \section{La gestione degli indirizzi} \label{sec:sock_addresses} +Negli esempi precedenti abbiamo sempre identificato le singole macchine +attraverso indirizzi numerici, sfruttando al più le funzioni di conversione +elementari illustrate in sez.~\ref{sec:sock_addr_func} che permettono di +passare da un indirizzo espresso in forma dotted decimal ad un numero. Vedremo +in questa sezione le funzioni utilizzate per poter identificare le varie +proprietà di un indirizzo (numero IP e porta) attraverso dei nomi simbolici +che vengano automaticamente tradotti nei rispettivi valori numerici. + + +\subsection{Il sistema del \textit{resolver}} +\label{sec:sock_resolver} + + Effettueremo in questa sezione una trattazione completa delle funzioni utilizzate per la gestione degli indirizzi dei socket. @@ -39,6 +51,8 @@ TCP, ed hanno poi significato analogo quando usate con altri socket, abbiamo preferito trattare l'argomento in generale in questa sezione piuttosto che nel capitolo dedicato alla trattazione generica dei socket. +\section{Altre funzioni di controllo} +\label{sec:TCP_sock_ctrl} diff --git a/sources/UDP_echo.c b/sources/UDP_echo.c index 8de9087..b14e1f6 100644 --- a/sources/UDP_echo.c +++ b/sources/UDP_echo.c @@ -26,7 +26,7 @@ * * Usage: echo -h give all info's * - * $Id: UDP_echo.c,v 1.1 2004/05/01 17:53:42 piccardi Exp $ + * $Id: UDP_echo.c,v 1.2 2004/05/02 13:10:32 piccardi Exp $ * ****************************************************************/ /* @@ -137,9 +137,6 @@ void ClientEcho(FILE * filein, int socket, struct sockaddr_in * serv_addr) printf("Errore in lettura: %s\n", strerror(errno)); return; } - if (nread == 0) { /* server closed connection, stop */ - return; - } recvbuff[nread] = 0; /* else read is ok, write on stdout */ if (fputs(recvbuff, stdout) == EOF) { perror("Errore in scrittura su terminale");