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