3 %% Copyright (C) 2004-2019 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{Gli altri tipi di socket}
13 \label{cha:other_socket}
15 Dopo aver trattato in cap.~\ref{cha:TCP_socket} i socket TCP, che
16 costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
17 questo capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
18 \textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
21 \section{I socket UDP}
22 \label{sec:UDP_socket}
24 Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
25 socket UDP: protocolli diffusi come NFS o il DNS usano principalmente questo
26 tipo di socket. Tratteremo in questa sezione le loro caratteristiche
27 principali e le modalità per il loro utilizzo.
30 \subsection{Le caratteristiche di un socket UDP}
31 \label{sec:UDP_characteristics}
33 Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che
34 non supporta le connessioni e non è affidabile: esso si appoggia direttamente
35 sopra IP (per i dettagli sul protocollo si veda sez.~\ref{sec:udp_protocol}).
36 I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
37 effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
38 vantaggio del protocollo è la velocità, non è necessario trasmettere le
39 informazioni di controllo ed il risultato è una trasmissione di dati più
42 Questo significa che a differenza dei socket TCP i socket UDP non supportano
43 una comunicazione di tipo \textit{stream} in cui si ha a disposizione un
44 flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
45 una comunicazione di tipo \textit{datagram}, in cui i dati arrivano in singoli
46 blocchi che devono essere letti integralmente.
48 Questo diverso comportamento significa anche che i socket UDP, pur
49 appartenendo alla famiglia \const{PF\_INET}\footnote{o \const{PF\_INET6}
50 qualora si usasse invece il protocollo IPv6, che pure supporta UDP.} devono
51 essere aperti quando si usa la funzione \func{socket} (si riveda quanto
52 illustrato a suo tempo in tab.~\ref{tab:sock_sock_valid_combinations})
53 utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
55 Questa differenza comporta ovviamente che anche le modalità con cui si usano i
56 socket UDP sono completamente diverse rispetto ai socket TCP, ed in
57 particolare non esistendo il concetto di connessione non esiste il meccanismo
58 del \textit{three way handshake} né quello degli stati del protocollo. In
59 realtà tutto quello che avviene nella comunicazione attraverso dei socket UDP
60 è la trasmissione di un pacchetto da un client ad un server o viceversa,
61 secondo lo schema illustrato in fig.~\ref{fig:UDP_packet-exchange}.
64 \centering \includegraphics[width=10cm]{img/udp_connection}
65 \caption{Lo schema di interscambio dei pacchetti per una comunicazione via
67 \label{fig:UDP_packet-exchange}
70 Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
71 un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
72 per mettersi in ascolto dei dati, questa è l'unica parte comune con un server
73 TCP. Non essendovi il concetto di connessione le funzioni \func{listen} ed
74 \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
75 dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
76 eventuale risposta sarà inviata con la funzione \func{sendto}.
78 Da parte del client invece, una volta creato il socket non sarà necessario
79 connettersi con \func{connect} (anche se, come vedremo in
80 sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un
81 significato comunque diverso) ma si potrà effettuare direttamente una
82 richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
83 leggere una eventuale risposta con la funzione \func{recvfrom}.
85 Anche se UDP è completamente diverso rispetto a TCP resta identica la
86 possibilità di gestire più canali di comunicazione fra due macchine
87 utilizzando le porte. In questo caso il server dovrà usare comunque la
88 funzione \func{bind} per scegliere la porta su cui ricevere i dati, e come nel
89 caso dei socket TCP si potrà usare il comando \cmd{netstat} per
90 verificare quali socket sono in ascolto:
92 [piccardi@gont gapil]# netstat -anu
93 Active Internet connections (servers and established)
94 Proto Recv-Q Send-Q Local Address Foreign Address State
95 udp 0 0 0.0.0.0:32768 0.0.0.0:*
96 udp 0 0 192.168.1.2:53 0.0.0.0:*
97 udp 0 0 127.0.0.1:53 0.0.0.0:*
98 udp 0 0 0.0.0.0:67 0.0.0.0:*
100 in questo caso abbiamo attivi il DNS (sulla porta 53, e sulla 32768 per la
101 connessione di controllo del server \cmd{named}) ed un server DHCP (sulla
104 Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
105 socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico
106 non si avranno indicazioni delle connessioni attive, proprio perché questo
107 concetto non esiste per i socket UDP, il kernel si limita infatti a ricevere i
108 pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
109 destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
110 unreachable} qualora non vi sia nessun processo in ascolto.
113 \subsection{Le funzioni \func{sendto} e \func{recvfrom}}
114 \label{sec:UDP_sendto_recvfrom}
116 Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni
117 principali usate per la trasmissione di dati attraverso i socket UDP (ed in
118 generale per i socket di tipo \textit{datagram}) sono \func{sendto} e
119 \func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che
120 non esistendo con UDP il concetto di connessione, non si può stabilire (come
121 avviene con i socket TCP grazie alla chiamata ad \func{accept} che li associa
122 ad una connessione) quali sono la sorgente e la destinazione dei dati che
123 passano sul socket.\footnote{anche se in alcuni casi, come quello di un client
124 che contatta un server, è possibile connettere il socket (vedi
125 sez.~\ref{sec:UDP_connect}), la necessità di \func{sendto} e \func{recvfrom}
126 resta, dato che questo è possibile solo sul lato del client.}
128 Per questo anche se in generale si possono comunque leggere i dati con
129 \func{read}, usando questa funzione non si sarà in grado di determinare da
130 quale fra i possibili corrispondenti (se ve ne sono più di uno, come avviene
131 sul lato del server) questi arrivino. E non sarà comunque possibile usare
132 \func{write} (che fallisce un errore di \errval{EDESTADDRREQ}) in quanto non
133 è determinato la destinazione che i dati avrebbero.
135 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
136 funzioni, che sono comunque utilizzabili in generale per la trasmissione di
137 dati attraverso qualunque tipo di socket. Esse hanno la caratteristica di
138 prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
139 la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
140 prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
141 prototipo illustrato è quello utilizzato dalla \acr{glibc}, che segue le
142 \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
143 \ctyp{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
144 usato un \texttt{unsigned int}; l'argomento \param{len} era \ctyp{int} nei
145 vari BSD4.* e nella \acr{libc4}, ma \type{size\_t} nella \acr{libc5}; infine
146 l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.*, nella \acr{libc4} e
147 nella \acr{libc5}.} è:
149 \headdecl{sys/types.h}
150 \headdecl{sys/socket.h}
152 \funcdecl{ssize\_t sendto(int sockfd, const void *buf, size\_t len, int
153 flags, const struct sockaddr *to, socklen\_t tolen)}
155 Trasmette un messaggio ad un altro socket.
157 \bodydesc{La funzione restituisce il numero di caratteri inviati in caso di
158 successo e -1 per un errore; nel qual caso \var{errno} viene impostata al
159 rispettivo codice di errore:
161 \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
162 l'operazione richiede che la funzione si blocchi.
163 \item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la
165 \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
166 specificato un indirizzo di destinazione.
167 \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
169 \item[\errcode{EMSGSIZE}] il tipo di socket richiede l'invio dei dati in un
170 blocco unico, ma la dimensione del messaggio lo rende impossibile.
171 \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
172 norma Linux non usa questo messaggio ma scarta silenziosamente i
174 \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
176 \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
177 il tipo di socket usato.
178 \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
179 riceverà anche un segnale di \signal{SIGPIPE}, a meno di non aver impostato
180 \const{MSG\_NOSIGNAL} in \param{flags}.
182 ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
183 \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
184 ai protocolli utilizzati.}
187 I primi tre argomenti sono identici a quelli della funzione \func{write} e
188 specificano il socket \param{sockfd} a cui si fa riferimento, il buffer
189 \param{buf} che contiene i dati da inviare e la relativa lunghezza
190 \param{len}. Come per \func{write} la funzione ritorna il numero di byte
191 inviati; nel caso di UDP però questo deve sempre corrispondere alla dimensione
192 totale specificata da \param{len} in quanto i dati vengono sempre inviati in
193 forma di pacchetto e non possono essere spezzati in invii successivi. Qualora
194 non ci sia spazio nel buffer di uscita la funzione si blocca (a meno di non
195 avere aperto il socket in modalità non bloccante), se invece non è possibile
196 inviare il messaggio all'interno di un unico pacchetto (ad esempio perché
197 eccede le dimensioni massime del protocollo sottostante utilizzato) essa
198 fallisce con l'errore di \errcode{EMSGSIZE}.
200 I due argomenti \param{to} e \param{tolen} servono a specificare la
201 destinazione del messaggio da inviare, e indicano rispettivamente la struttura
202 contenente l'indirizzo di quest'ultima e la sua dimensione; questi argomenti
203 vanno specificati stessa forma in cui li si sarebbero usati con
204 \func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura
205 contenente l'indirizzo IP e la porta di destinazione verso cui si vogliono
206 inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando
207 socket diversi si sarebbero dovute utilizzare le rispettive strutture degli
210 Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
211 TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
212 caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
213 specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono
214 essi dovranno essere inizializzati rispettivamente a \val{NULL} e 0;
215 normalmente quando si opera su un socket connesso essi vengono ignorati, ma
216 qualora si sia specificato un indirizzo è possibile ricevere un errore di
219 Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
220 come maschera binaria che permette di impostare una serie di modalità di
221 funzionamento della comunicazione attraverso il socket (come
222 \constd{MSG\_NOSIGNAL} che impedisce l'invio del segnale \signal{SIGPIPE}
223 quando si è già chiuso il capo locale della connessione). Torneremo con
224 maggiori dettagli sul significato di questo argomento in
225 sez.~\ref{sec:net_sendmsg}, dove tratteremo le funzioni avanzate dei socket,
226 per il momento ci si può limitare ad usare sempre un valore nullo.
228 La seconda funzione utilizzata nella comunicazione fra socket UDP è
229 \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
230 suo prototipo\footnote{il prototipo è quello della \acr{glibc} che segue le
231 \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e la
232 \acr{libc5} usano un \ctyp{int} come valore di ritorno; per gli argomenti
233 \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
234 infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, la
235 \acr{libc4} e la \acr{libc5}.} è:
237 \headdecl{sys/types.h}
238 \headdecl{sys/socket.h}
240 \funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
241 flags, const struct sockaddr *from, socklen\_t *fromlen)}
243 Riceve un messaggio da un socket.
245 \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
246 successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
249 \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
250 l'operazione richiede che la funzione si blocchi, oppure si è impostato un
251 timeout in ricezione e questo è scaduto.
252 \item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato
253 la connessione (in genere perché il relativo servizio non è disponibile).
254 \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
257 ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
258 \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
259 ai protocolli utilizzati.}
262 Come per \func{sendto} i primi tre argomenti sono identici agli analoghi di
263 \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel
264 buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
265 o di tipo \textit{stream}) i byte in eccesso che non sono stati letti possono
266 rispettivamente andare persi o restare disponibili per una lettura successiva.
267 Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
268 il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
269 \errcode{EAGAIN}. Qualora \param{len} ecceda la dimensione del pacchetto la
270 funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
271 comunque il numero di byte letti.
273 I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
274 l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
275 opportunamente inizializzati; il primo deve contenere il puntatore alla
276 struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
277 puntatore alla variabile con la dimensione di detta struttura. Si tenga
278 presente che mentre il contenuto della struttura \ctyp{sockaddr} cui punta
279 \param{from} può essere qualunque, la variabile puntata da \param{fromlen}
280 deve essere opportunamente inizializzata a \code{sizeof(sockaddr)},
281 assicurandosi che la dimensione sia sufficiente a contenere tutti i dati
282 dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
283 serve ad indicare la struttura corrispondente allo specifico tipo di
284 indirizzo richiesto, il valore di \param{fromlen} pone un limite alla
285 quantità di dati che verranno scritti sulla struttura puntata da
286 \param{from} e se è insufficiente l'indirizzo risulterà corrotto.} Al
287 ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
288 lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
289 \textit{value result argument}). Se non si è interessati a questa
290 informazione, entrambi gli argomenti devono essere inizializzati al valore
293 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
294 usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
295 questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
296 vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
297 specificando un valore nullo per \param{len}. Allo stesso modo è possibile
298 ricevere con \func{recvfrom} un valore di ritorno di 0 byte, senza che questo
299 possa configurarsi come una chiusura della connessione\footnote{dato che la
300 connessione non esiste, non ha senso parlare di chiusura della connessione,
301 questo significa anche che con i socket UDP non è necessario usare
302 \func{close} o \func{shutdown} per terminare la comunicazione.} o come una
303 cessazione delle comunicazioni.
307 \subsection{Un client UDP elementare}
308 \label{sec:UDP_daytime_client}
310 Vediamo allora come implementare un primo client elementare con dei socket
311 UDP. Ricalcando quanto fatto nel caso dei socket TCP prenderemo come primo
312 esempio l'uso del servizio \textit{daytime}, utilizzando questa volta UDP. Il
313 servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
314 che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
315 UDP al server (di contenuto non specificato), il quale risponderà a inviando a
316 sua volta un pacchetto UDP contenente la data.
318 \begin{figure}[!htbp]
319 \footnotesize \centering
320 \begin{minipage}[c]{\codesamplewidth}
321 \includecodesample{listati/UDP_daytime.c}
324 \caption{Sezione principale del client per il servizio \textit{daytime} su
326 \label{fig:UDP_daytime_client}
329 In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
330 codice del nostro client, il sorgente completo si trova nel file
331 \file{UDP\_daytime.c} distribuito con gli esempi allegati alla guida; al
332 solito si è tralasciato di riportare in figura la sezione relativa alla
333 gestione delle opzioni a riga di comando (nel caso praticamente assenti).
335 Il programma inizia (\texttt{\small 9--12}) con la creazione del socket, al
336 solito uscendo dopo aver stampato un messaggio in caso errore. Si noti come in
337 questo caso, rispetto all'analogo client basato su socket TCP di
338 fig.~\ref{fig:TCP_daytime_client_code} si sia usato per il tipo di socket il
339 valore \const{SOCK\_DGRAM}, pur mantenendosi nella stessa famiglia data da
342 Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
343 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
344 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
345 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
346 (\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare
347 dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
348 Si noti come questa sezione sia identica a quella del client TCP di
349 fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
350 di UDP al posto di TCP è stata effettuata quando si è creato il socket.
352 Una volta completate le inizializzazioni inizia il corpo principale del
353 programma, il primo passo è inviare, come richiesto dal protocollo, un
354 pacchetto al server. Questo lo si fa (\texttt{\small 16}) inviando un
355 pacchetto vuoto (si ricordi quanto detto in
356 sez.~\ref{sec:UDP_sendto_recvfrom}) con \func{sendto}, avendo cura di passare
357 un valore nullo per il puntatore al buffer e la lunghezza del messaggio. In
358 realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
359 server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
361 Verificato (\texttt{\small 24--27}) che non ci siano stati errori nell'invio
362 si provvede (\texttt{\small 28}) ad invocare \func{recvfrom} per ricevere la
363 risposta del server. Si controlla poi (\texttt{\small 29--32}) che non vi
364 siano stati errori in ricezione (uscendo con un messaggio in caso contrario);
365 se è tutto a posto la variabile \var{nread} conterrà la dimensione del
366 messaggio di risposta inviato dal server che è stato memorizzato su
367 \var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
368 provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
369 lettura\footnote{si ricordi che, come illustrato in
370 sez.~\ref{sec:TCP_daytime_client}, il server invia in risposta una stringa
371 contenente la data, terminata dai due caratteri CR e LF, che pertanto prima
372 di essere stampata deve essere opportunamente terminata con un NUL.} e a
373 stamparla (\texttt{\small 36}) sullo standard output, controllando anche in
374 questo caso (\texttt{\small 36--38}) l'esito dell'operazione, ed uscendo con
375 un messaggio in caso di errore.
377 Se pertanto si è avuto cura di attivare il server del servizio
378 \textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
379 \textsl{superdemone} \cmd{inetd}, per cui basta abilitarlo nel file di
380 configurazione di quest'ultimo, avendo cura di predisporre il servizio su
381 UDP.} potremo verificare il funzionamento del nostro client interrogando
384 [piccardi@gont sources]$ ./daytime 127.0.0.1
385 Sat Mar 20 23:17:13 2004
387 ed osservando il traffico con uno sniffer potremo effettivamente vedere lo
388 scambio dei due pacchetti, quello vuoto di richiesta, e la risposta del
391 [root@gont gapil]# tcpdump -i lo
392 tcpdump: listening on lo
393 23:41:21.645579 localhost.32780 > localhost.daytime: udp 0 (DF)
394 23:41:21.645710 localhost.daytime > localhost.32780: udp 26 (DF)
397 Una differenza fondamentale del nostro client è che in questo caso, non
398 disponendo di una connessione, è per lui impossibile riconoscere errori di
399 invio relativi alla rete. La funzione \func{sendto} infatti riporta solo
400 errori locali, i dati vengono comunque scritti e la funzione ritorna senza
401 errori anche se il server non è raggiungibile o non esiste un server in
402 ascolto sull'indirizzo di destinazione. Questo comporta ad esempio che se si
403 usa il nostro programma interrogando un server inesistente questo resterà
404 perennemente bloccato nella chiamata a \func{recvfrom}, fin quando non lo
405 interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
406 a questa problematica.
409 \subsection{Un server UDP elementare}
410 \label{sec:UDP_daytime_server}
412 Nella sezione precedente abbiamo visto come scrivere un client elementare per
413 servizio \textit{daytime}, vediamo in questa come deve essere scritto un
414 server. Si ricordi che il compito di quest'ultimo è quello di ricevere un
415 pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
416 stringa con la data corrente.
418 \begin{figure}[!htbp]
419 \footnotesize \centering
420 \begin{minipage}[c]{\codesamplewidth}
421 \includecodesample{listati/UDP_daytimed.c}
424 \caption{Sezione principale del server per il servizio \textit{daytime} su
426 \label{fig:UDP_daytime_server}
429 In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
430 codice del nostro client, il sorgente completo si trova nel file
431 \file{UDP\_daytimed.c} distribuito con gli esempi allegati alla guida; anche
432 in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
433 riga di comando (la sola presente è \texttt{-v} che permette di stampare a
434 video l'indirizzo associato ad ogni richiesta).
436 Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
437 sostanzialmente identica a quella dell'analogo server per TCP illustrato in
438 fig.~\ref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10})
439 con il creare il socket, uscendo con un messaggio in caso di errore
440 (\texttt{\small 10--13}), e di nuovo la sola differenza con il caso precedente
441 è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
442 si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
443 usata da \func{bind}; si cancella (\texttt{\small 15}) preventivamente il
444 contenuto, si imposta (\texttt{\small 16}) la famiglia dell'indirizzo, la
445 porta (\texttt{\small 17}) e l'indirizzo (\texttt{\small 18}) su cui si
446 riceveranno i pacchetti. Si noti come in quest'ultimo sia l'indirizzo
447 generico \const{INADDR\_ANY}; questo significa (si ricordi quanto illustrato
448 in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
449 qualunque degli indirizzi presenti sulle interfacce di rete della macchina.
451 Completata l'inizializzazione tutto quello che resta da fare è eseguire
452 (\texttt{\small 20--23}) la chiamata a \func{bind}, controllando la presenza
453 di eventuali errori, ed uscendo con un avviso qualora questo fosse il caso.
454 Nel caso di socket UDP questo è tutto quello che serve per consentire al
455 server di ricevere i pacchetti a lui indirizzati, e non è più necessario
456 chiamare successivamente \func{listen}. In questo caso infatti non esiste il
457 concetto di connessione, e quindi non deve essere predisposta una coda delle
458 connessioni entranti. Nel caso di UDP i pacchetti arrivano al kernel con un
459 certo indirizzo ed una certa porta di destinazione, il kernel controlla se
460 corrispondono ad un socket che è stato \textsl{legato} ad essi con
461 \func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
462 socket, così che il programma possa leggerlo, altrimenti risponderà alla
463 macchina che ha inviato il pacchetto con un messaggio ICMP di tipo
464 \textit{port unreachable}.
466 Una volta completata la fase di inizializzazione inizia il corpo principale
467 (\texttt{\small 24--44}) del server, mantenuto all'interno di un ciclo
468 infinito in cui si trattano le richieste. Il ciclo inizia (\texttt{\small 26})
469 con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
470 inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
471 volte che un pacchetto viene inviato al server, in modo da poter ricavare da
472 esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
473 questo motivo in questo caso (al contrario di quanto fatto in
474 fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
475 \var{addr} e \var{len} alla funzione. Dopo aver controllato (\texttt{\small
476 27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
477 qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
478 l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
479 caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
480 richiesta (questa sezione è identica a quella del server TCP illustrato in
481 fig.~\ref{fig:TCP_daytime_cunc_server_code}).
483 Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
484 (\texttt{\small 36}) e costruire (\texttt{\small 37}) la stringa di risposta,
485 che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
486 avendo al solito cura di controllare (\texttt{\small 40--42}) lo stato di
487 uscita della funzione e trattando opportunamente la condizione di errore.
489 Si noti come per le peculiarità del protocollo si sia utilizzato un server
490 iterativo, che processa le richieste una alla volta via via che gli arrivano.
491 Questa è una caratteristica comune dei server UDP, conseguenza diretta del
492 fatto che non esiste il concetto di connessione, per cui non c'è la necessità
493 di trattare separatamente le singole connessioni. Questo significa anche che è
494 il kernel a gestire la possibilità di richieste multiple in contemporanea;
495 quello che succede è semplicemente che il kernel accumula in un buffer in
496 ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
497 volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
498 compito del server distribuire le risposte sulla base dell'indirizzo da cui
499 provengono le richieste.
502 \subsection{Le problematiche dei socket UDP}
503 \label{sec:UDP_problems}
505 L'esempio del servizio \textit{daytime} illustrato nelle precedenti sezioni
506 è in realtà piuttosto particolare, e non evidenzia quali possono essere i
507 problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
508 connessione che sono tipiche dei socket UDP. In tal caso infatti il protocollo
509 è estremamente semplice, dato che la comunicazione consiste sempre in una
510 richiesta seguita da una risposta, per uno scambio di dati effettuabile con un
511 singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
512 complessi da rilevare.
514 Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
515 la risposta del server si perdono, il client resterà permanentemente bloccato
516 nella chiamata a \func{recvfrom}. Per evidenziare meglio quali problemi si
517 possono avere proviamo allora con un servizio leggermente più complesso come
520 \begin{figure}[!htbp]
521 \footnotesize \centering
522 \begin{minipage}[c]{\codesamplewidth}
523 \includecodesample{listati/UDP_echo_first.c}
526 \caption{Sezione principale della prima versione client per il servizio
527 \textit{echo} su UDP.}
528 \label{fig:UDP_echo_client}
531 In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
532 del nostro client elementare per il servizio \textit{echo} (al solito il
533 codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
534 client visto in fig.~\ref{fig:TCP_echo_client_1} sono che al solito si crea
535 (\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
536 presente nessuna chiamata a \func{connect}. Per il resto il funzionamento del
537 programma è identico, e tutto il lavoro viene effettuato attraverso la
538 chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
539 però prende un argomento in più, che è l'indirizzo del socket.
541 \begin{figure}[!htbp]
542 \footnotesize \centering
543 \begin{minipage}[c]{\codesamplewidth}
544 \includecodesample{listati/UDP_ClientEcho_first.c}
547 \caption{Codice della funzione \func{ClientEcho} usata dal client per il
548 servizio \textit{echo} su UDP.}
549 \label{fig:UDP_echo_client_echo}
552 Ovviamente in questo caso il funzionamento della funzione, il cui codice è
553 riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
554 rispetto alla analoga del server TCP, e dato che non esiste una connessione
555 questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
558 Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
559 più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
560 6--30}) che parte dalla lettura (\texttt{\small 7}) sul buffer di invio
561 \var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
562 (\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
563 immediatamente causando anche la susseguente terminazione del programma.
565 Altrimenti si procede (\texttt{\small 10--11}) all'invio della stringa al
566 destinatario invocando \func{sendto}, utilizzando, oltre alla stringa appena
567 letta, gli argomenti passati nella chiamata a \func{ClientEcho}, ed in
568 particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
569 (\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
570 (\texttt{\small 13--14}) ad uscire con un messaggio di errore.
572 Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
573 leggere l'eventuale risposta del server con \func{recvfrom}; si noti come in
574 questo caso si sia scelto di ignorare l'indirizzo dell'eventuale pacchetto di
575 risposta, controllando (\texttt{\small 18--21}) soltanto la presenza di un
576 errore (nel qual caso al solito si ritorna dopo la stampa di un adeguato
577 messaggio). Si noti anche come, rispetto all'analoga funzione
578 \func{ClientEcho} utilizzata nel client TCP illustrato in
579 sez.~\ref{sec:TCP_echo_client} non si sia controllato il caso di un messaggio
580 nullo, dato che, nel caso di socket UDP, questo non significa la terminazione
583 L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
584 stringa di risposta nel relativo buffer per poi provvedere alla sua stampa
585 sullo standard output, eseguendo il solito controllo (ed eventuale uscita con
586 adeguato messaggio informativo) in caso di errore.
588 In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
589 problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
590 (nel caso dell'esempio seguente su una VPN, attraverso una ADSL abbastanza
591 congestionata) e in modalità non interattiva, la probabilità di perdere
592 qualche pacchetto aumenta, ed infatti, eseguendo il comando come:
594 [piccardi@gont sources]$ cat UDP_echo.c | ./echo 192.168.1.120
597 * Copyright (C) 2004 Simone Piccardi
601 * Include needed headers
604 si otterrà che, dopo aver correttamente stampato alcune righe, il programma si
605 blocca completamente senza stampare più niente. Se al contempo si fosse tenuto
606 sotto controllo il traffico UDP diretto o proveniente dal servizio
607 \textit{echo} con \cmd{tcpdump} si sarebbe ottenuto:
609 [root@gont gapil]# tcpdump \( dst port 7 or src port 7 \)
612 18:48:16.390255 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
613 18:48:17.177613 192.168.1.120.echo > gont.earthsea.ea.32788: udp 4 (DF)
614 18:48:17.177790 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 26 (DF)
615 18:48:17.964917 192.168.1.120.echo > gont.earthsea.ea.32788: udp 26 (DF)
616 18:48:17.965408 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
618 che come si vede il traffico fra client e server si interrompe dopo l'invio di
619 un pacchetto UDP per il quale non si è ricevuto risposta.
621 Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
622 una richiesta non arriva a destinazione, il nostro programma si bloccherà
623 nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
624 in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
625 pacchetti, il risultato è diverso, se si lancia al solito il programma e si
626 prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
627 se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
629 [root@gont gapil]# tcpdump \( dst 192.168.0.2 and src 192.168.1.120 \) \
630 or \( src 192.168.0.2 and dst 192.168.1.120 \)
631 tcpdump: listening on eth0
632 00:43:27.606944 gont.earthsea.ea.32789 > 192.168.1.120.echo: udp 6 (DF)
633 00:43:27.990560 192.168.1.120 > gont.earthsea.ea: icmp: 192.168.1.120 udp port
634 echo unreachable [tos 0xc0]
636 cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
637 irraggiungibile che ci segnala che la porta in questione non risponde.
639 Ci si può chiedere allora perché, benché la situazione di errore sia
640 rilevabile, questa non venga segnalata. Il luogo più naturale in cui
641 riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
642 di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
643 questo punto però è impossibile, dato che l'interfaccia di programmazione
644 richiede che la funzione ritorni non appena il kernel invia il
645 pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
646 una situazione cioè in cui la condizione di errore viene rilevata in maniera
647 asincrona rispetto all'operazione che l'ha causata, una eventualità
648 piuttosto comune quando si ha a che fare con la rete, tutti i pacchetti ICMP
649 che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
650 una attesa di una risposta che potrebbe essere molto lunga (si noti infatti
651 che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
654 Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
655 comunque bloccata in attesa di una risposta che nel caso non arriverà mai. La
656 ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
657 Stevens in \cite{UNP2} con il seguente esempio: si consideri un client che
658 invia tre pacchetti a tre diverse macchine, due dei quali vengono regolarmente
659 ricevuti, mentre al terzo, non essendo presente un server sulla relativa
660 macchina, viene risposto con un messaggio ICMP come il precedente. Detto
661 messaggio conterrà anche le informazioni relative ad indirizzo e porta del
662 pacchetto che ha fallito, però tutto quello che il kernel può restituire al
663 programma è un codice di errore in \var{errno}, con il quale è impossibile di
664 distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
665 stata fatta la scelta di non riportare un errore su un socket UDP, a meno che,
666 come vedremo in sez.~\ref{sec:UDP_connect}, questo non sia connesso.
670 \subsection{L'uso della funzione \func{connect} con i socket UDP}
671 \label{sec:UDP_connect}
673 Come illustrato in sez.~\ref{sec:UDP_characteristics} essendo i socket UDP
674 privi di connessione non è necessario per i client usare \func{connect} prima
675 di iniziare una comunicazione con un server. Ciò non di meno abbiamo accennato
676 come questa possa essere utilizzata per gestire la presenza di errori
679 Quando si chiama \func{connect} su di un socket UDP tutto quello che succede è
680 che l'indirizzo passato alla funzione viene registrato come indirizzo di
681 destinazione del socket. A differenza di quanto avviene con TCP non viene
682 scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
683 qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
684 più necessario usare l'argomento \param{to} di \func{sendto} per specificare
685 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
686 le normali funzioni \func{read} e \func{write} che a questo punto non
687 falliranno più con l'errore di \errval{EDESTADDRREQ}.\footnote{in realtà si
688 può anche continuare ad usare la funzione \func{sendto}, ma in tal caso
689 l'argomento \param{to} deve essere inizializzato a \val{NULL}, e
690 \param{tolen} deve essere inizializzato a zero, pena un errore di
693 Una volta che il socket è connesso cambia però anche il comportamento in
694 ricezione; prima infatti il kernel avrebbe restituito al socket qualunque
695 pacchetto ricevuto con un indirizzo di destinazione corrispondente a quello
696 del socket, senza nessun controllo sulla sorgente; una volta che il socket
697 viene connesso saranno riportati su di esso solo i pacchetti con un indirizzo
698 sorgente corrispondente a quello a cui ci si è connessi.
700 Infine quando si usa un socket connesso, venendo meno l'ambiguità segnalata
701 alla fine di sez.~\ref{sec:UDP_problems}, tutti gli eventuali errori asincroni
702 vengono riportati alle funzioni che operano su di esso; pertanto potremo
703 riscrivere il nostro client per il servizio \textit{echo} con le modifiche
704 illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
706 \begin{figure}[!htbp]
707 \footnotesize \centering
708 \begin{minipage}[c]{\codesamplewidth}
709 \includecodesample{listati/UDP_echo.c}
712 \caption{Seconda versione del client del servizio \textit{echo} che utilizza
713 socket UDP connessi.}
714 \label{fig:UDP_echo_conn_cli}
717 Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
718 l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
719 chiamata alla funzione di gestione del protocollo, che a sua volta è stata
720 modificata eliminando l'indirizzo passato come argomento e sostituendo le
721 chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
722 \func{write} come illustrato dal nuovo codice riportato in
723 fig.~\ref{fig:UDP_echo_conn_echo_client}.
725 \begin{figure}[!htbp]
726 \footnotesize \centering
727 \begin{minipage}[c]{\codesamplewidth}
728 \includecodesample{listati/UDP_ClientEcho.c}
731 \caption{Seconda versione della funzione \func{ClientEcho}.}
732 \label{fig:UDP_echo_conn_echo_client}
735 Utilizzando questa nuova versione del client si può verificare che quando ci
736 si rivolge verso un indirizzo inesistente o su cui non è in ascolto un server
737 si è in grado rilevare l'errore, se infatti eseguiamo il nuovo programma
738 otterremo un qualcosa del tipo:
740 [piccardi@gont sources]$ ./echo 192.168.1.1
742 Errore in lettura: Connection refused
745 Ma si noti che a differenza di quanto avveniva con il client TCP qui l'errore
746 viene rilevato soltanto dopo che si è tentato di inviare qualcosa, ed in
747 corrispondenza al tentativo di lettura della risposta. Questo avviene perché
748 con UDP non esiste una connessione, e fintanto che non si invia un pacchetto
749 non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
750 ricezione del pacchetto ICMP \textit{destination unreachable} emesso dalla
751 macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
752 il kernel potrà riportare detto errore in \textit{user space} in maniera non
753 ambigua, ed esso apparirà alla successiva lettura sul socket.
755 Si tenga presente infine che l'uso dei socket connessi non risolve l'altro
756 problema del client, e cioè il fatto che in caso di perdita di un pacchetto
757 questo resterà bloccato permanentemente in attesa di una risposta. Per
758 risolvere questo problema l'unico modo sarebbe quello di impostare un
759 \textit{timeout} o riscrivere il client in modo da usare l'I/O non bloccante.
763 \index{socket!locali|(}
766 \section{I socket \textit{Unix domain}}
767 \label{sec:unix_socket}
769 Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
770 girano sulla stessa macchina, non siano strettamente attinenti alla rete, li
771 tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
772 l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella
777 \subsection{Il passaggio di file descriptor}
778 \label{sec:sock_fd_passing}
782 \index{socket!locali|)}
785 \section{Altri socket}
786 \label{sec:socket_other}
788 Tratteremo in questa sezione gli altri tipi particolari di socket supportati
789 da Linux, come quelli relativi a particolare protocolli di trasmissione, i
790 socket \textit{netlink} che definiscono una interfaccia di comunicazione con
791 il kernel, ed i \textit{packet socket} che consentono di inviare pacchetti
792 direttamente a livello delle interfacce di rete.
794 \subsection{I socket \textit{raw}}
795 \label{sec:socket_raw}
797 Tratteremo in questa sezione i cosiddetti \textit{raw socket}, con i quali si
798 possono \textsl{forgiare} direttamente i pacchetti a tutti i livelli dello
799 stack dei protocolli.
801 \subsection{I socket \textit{netlink}}
802 \label{sec:socket_netlink}
805 \subsection{I \textit{packet socket}}
806 \label{sec:packet_socket}
809 % articoli interessanti:
810 % http://www.linuxjournal.com/article/5617
811 % http://www.linuxjournal.com/article/4659
815 % LocalWords: socket cap TCP UDP domain sez NFS DNS stream datagram PF INET to
816 % LocalWords: IPv tab SOCK DGRAM three way handshake client fig bind listen AF
817 % LocalWords: accept recvfrom sendto connect netstat named DHCP kernel ICMP CR
818 % LocalWords: port unreachable read write glibc Specification flags int BSD LF
819 % LocalWords: libc unsigned len size tolen sys ssize sockfd const void buf MSG
820 % LocalWords: struct sockaddr socklen errno EAGAIN ECONNRESET EDESTADDRREQ RFC
821 % LocalWords: EISCONN EMSGSIZE ENOBUFS ENOTCONN EOPNOTSUPP EPIPE SIGPIPE EBADF
822 % LocalWords: NOSIGNAL EFAULT EINVAL EINTR ENOMEM ENOTSOCK NULL fromlen from
823 % LocalWords: ECONNREFUSED value result argument close shutdown daytime nell'
824 % LocalWords: memset inet pton nread NUL superdemone inetd sniffer daytimed
825 % LocalWords: INADDR ANY addr echo ClientEcho sendbuff serv VPN tcpdump l'I
826 % LocalWords: Stevens destination descriptor raw stack netlink packet
832 %%% TeX-master: "gapil"
projects / gapil.git / blob