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 "Prefazione",
   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 \capref{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 deiit
  17 \textit{Unix domain} già incontrati in \secref{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 \secref{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 \secref{sec:udp_protocol}).  I
  35 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 \tabref{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 \figref{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 \figref{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 \secref{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 \secref{sec:UDP_characteristics} le due funzioni principali
 117 usate per la trasmissione di dati attraverso i socket UDP sono \func{sendto} e
 118 \func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che
 119 non esistendo con UDP il concetto di connessione, non si ha neanche a
 120 disposizione un \textsl{socket connesso} su cui sia possibile usare
 121 direttamente \func{read} e \func{write} avendo già stabilito (grazie alla
 122 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 attraveso 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 richede che la funzione si blocchi.
 153   \item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la
 154     conessione.
 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 contentente 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} devrà 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 devranno essere inizializzati rispettivamente a \const{NULL} e 0;
 205 normalmente quando si opera su un socket conesso 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 \secref{sec:xxx_sendmsg}, dove
 215 tratteremo le funzioni avanzate dei socket, per il momento ci si può limitare
 216 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 richede 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 \textit{value return
 268   argoment}).  Se non si è interessati a questa informazione, entrambi gli
 269 argomenti devono essere inizializzati al valore \const{NULL}.
 270
 271 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
 272 usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
 273 questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
 274 vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
 275 specificando un valore nullo per \param{len}. Allo stesso modo è possibile
 276 ricevere con \func{recvfrom} un valore di ritorno di 0 byte, senza che questo
 277 possa configurarsi come una chiusura della connessione\footnote{dato che la
 278   connessione non esiste, non ha senso parlare di chiusura della connessione,
 279   questo significa anche che con i socket UDP non è necessario usare
 280   \func{close} o \func{shutdown} per terminare la cominicazione.} o come una
 281 cessazione delle comunicazioni.
 282
 283
 284
 285 \subsection{Un client UDP elementare}
 286 \label{sec:UDP_daytime_client}
 287
 288 Vediamo allora come implementare un primo client elementare con dei socket
 289 UDP.  Ricalcando quanto fatto nel caso dei socket TCP prenderemo come primo
 290 esempio l'uso del servizio \textit{daytime}, utilizzando questa volta UDP. Il
 291 servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
 292 che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
 293 UDP al server (di contenuto non specificato), il quale risponderà a inviando a
 294 sua volta un pacchetto UDP contenente la data.
 295
 296 \begin{figure}[!htb]
 297   \footnotesize \centering
 298   \begin{minipage}[c]{15.6cm}
 299     \includecodesample{listati/UDP_daytime.c}
 300   \end{minipage}
 301   \normalsize
 302   \caption{Sezione principale del client per il servizio \textit{daytime} su
 303     UDP.}
 304   \label{fig:UDP_daytime_client}
 305 \end{figure}
 306
 307 In \figref{fig:UDP_daytime_client} è riportato la sezione principale del
 308 codice del nostro client, il sorgente completo si trova nel file
 309 \file{UDP\_daytime.c} distribuito con gli esempi allegati alla guida; al
 310 solito si è tralasciato di riportare in figura la sezione relativa alla
 311 gestione delle opzioni a riga di comando (nel caso praticamente assenti).
 312
 313 Il programma inizia (\texttt{\small 9--12}) con la creazione del socket, al
 314 solito uscendo dopo aver stampato un messaggio in caso errore. Si noti come in
 315 questo caso, rispetto all'analogo client basato su socket TCP di
 316 \figref{fig:TCP_daytime_client_code} si sia usato per il tipo di socket il
 317 valore \const{SOCK\_DGRAM}, pur mantenendosi nella stessa famiglia data da
 318 \const{AF\_INET}.
 319
 320 Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
 321 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
 322 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
 323 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
 324 (\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare dal
 325 parametro passato a riga di comando, convertendolo con \func{inet\_pton}. Si
 326 noti come questa sezione sia identica a quella del client TCP di
 327 \figref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso di
 328 UDP al posto di TCP è stata effettuata quando si è creato il socket.
 329
 330 Una volta completate le inizializzazioni inizia il corpo principale del
 331 programma, il primo passo è inviare, come richiesto dal protocollo, un
 332 pacchetto al server. Questo lo si fa (\texttt{\small 16}) inviando un
 333 pacchetto vuoto (si ricordi quanto detto in \secref{sec:UDP_sendto_recvfrom})
 334 con \func{sendto}, avendo cura di passare un valore nullo per il puntatore al
 335 buffer e la lunghezza del messaggio. In realtà il protocollo non richiede che
 336 il pacchetto sia vuoto, ma dato che il server comunque ne ignorerà il
 337 contenuto, è inutile inviare dei dati.
 338
 339 Verificato (\texttt{\small 24--27}) che non ci siano stati errori nell'invio
 340 si provvede (\texttt{\small 28}) ad invocare \func{recvfrom} per ricevere la
 341 risposta del server. Si controlla poi (\texttt{\small 29--32}) che non vi
 342 siano stati errori in ricezione (uscendo con un messaggio in caso contrario);
 343 se è tutto a posto la variabile \var{nread} conterrà la dimensione del
 344 messaggio di risposta inviato dal server che è stato memorizzato su
 345 \var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
 346 provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
 347 lettura\footnote{si ricordi che, come illustrato in
 348   \secref{sec:TCP_daytime_client}, il server invia in risposta una stringa
 349   contenente la data, terminata dai due carratteri CR e LF, che pertanto prima
 350   di essere stampata deve essere opportunamente terminata con un NUL.} e a
 351 stamparla (\texttt{\small 36}) sullo standard output, controllando anche in
 352 questo caso (\texttt{\small 36--38}) l'esito dell'operazione, ed uscendo con
 353 un messaggio in caso di errore.
 354
 355 Se pertanto si è avuto cura di attivare il server del servizio
 356 \textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
 357   \textsl{superdemone} \cmd{inetd}, per cui basta abilitarlo nel file di
 358   configurazione di quest'ultimo, avendo cura di predisporre il servizio su
 359   UDP.} potremo verificare il funzionamento del nostro client interrogando
 360 quest'ultimo con:
 361 \begin{verbatim}
 362 [piccardi@gont sources]$ ./daytime 127.0.0.1
 363 Sat Mar 20 23:17:13 2004
 364 \end{verbatim}%$
 365 ed osservando il traffico con uno sniffer potremo effettivamente vedere lo
 366 scambio dei due pacchetti, quello vuoto di richiesta, e la risposta del
 367 server:
 368 \begin{verbatim}
 369 [root@gont gapil]# tcpdump -i lo
 370 tcpdump: listening on lo
 371 23:41:21.645579 localhost.32780 > localhost.daytime: udp 0 (DF)
 372 23:41:21.645710 localhost.daytime > localhost.32780: udp 26 (DF)
 373 \end{verbatim}
 374
 375 Una differenza fondamentale del nostro client è che in questo caso, non
 376 disponendo di una connessione, è per lui impossibile riconoscere errori di
 377 invio relativi alla rete. La funzione \func{sendto} infatti riporta solo
 378 errori locali, i dati vengono comunque scritti e la funzione ritorna senza
 379 errori anche se il server non è raggiungibile o non esiste un server in
 380 ascolto sull'indirizzo di destinazione. Questo comporta ad esempio che se si
 381 usa il nostro programma interrogando un server inesistente questo resterà
 382 perennemente bloccato nella chiamata a \func{recvfrom}, fin quando non lo
 383 interromperemo. Vedremo in \secref{sec:UDP_connect} come si può porre rimedio
 384 a questa problematica.
 385
 386
 387 \subsection{Un server UDP elementare}
 388 \label{sec:UDP_daytime_server}
 389
 390 Nella sezione precedente abbiamo visto come scrivere un client elementare per
 391 servizio \textit{daytime}, vediamo in questa come deve essere scritto un
 392 server.  Si ricordi che il compito di quest'ultimo è quello di ricevere un
 393 pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
 394 stringa con la data corrente.
 395
 396 \begin{figure}[!htb]
 397   \footnotesize \centering
 398   \begin{minipage}[c]{15.6cm}
 399     \includecodesample{listati/UDP_daytimed.c}
 400   \end{minipage}
 401   \normalsize
 402   \caption{Sezione principale del server per il servizio \textit{daytime} su
 403     UDP.}
 404   \label{fig:UDP_daytime_server}
 405 \end{figure}
 406
 407 In \figref{fig:UDP_daytime_server} è riportato la sezione principale del
 408 codice del nostro client, il sorgente completo si trova nel file
 409 \file{UDP\_daytimed.c} distribuito con gli esempi allegati alla guida; anche
 410 in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
 411 riga di comando (la sola presente è \texttt{-v} che permette di stampare a
 412 video l'indirizzo associato ad ogni richiesta).
 413
 414 Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
 415 sostanzialmente identica a quella dell'analogo server per TCP illustrato in
 416 \figref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10}) con
 417 il creare il socket, uscendo con un messaggio in caso di errore
 418 (\texttt{\small 10--13}), e di nuovo la sola differenza con il caso precedente
 419 è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
 420 si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
 421 usata da \func{bind}; si cancella (\texttt{\small 15}) preventivamente il
 422 contenuto, si imposta (\texttt{\small 16}) la famiglia dell'indirizzo, la
 423 porta (\texttt{\small 17}) e l'indirizzo (\texttt{\small 18}) su cui si
 424 riceveranno i pacchetti.  Si noti come in quest'ultimo sia l'indirizzo
 425 generico \const{INADDR\_ANY}; questo significa (si ricordi quanto illustrato
 426 in \secref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
 427 qualunque degli indirizzi presenti sulle interfacce di rete della macchina.
 428
 429 Completata l'inizializzazione tutto quello che resta da fare è eseguire
 430 (\texttt{\small 20--23}) la chiamata a \func{bind}, controllando la presenza
 431 di eventuali errori, ed uscendo con un avviso qualora questo fosse il caso.
 432 Nel caso di socket UDP questo è tutto quello che serve per consentire al
 433 server di ricevere i pacchetti a lui indirizzati, e non è più necessario
 434 chiamare successivamente \func{listen}. In questo caso infatti non esiste il
 435 concetto di connessione, e quindi non deve essere predisposta una coda delle
 436 connessioni entranti. Nel caso di UDP i pacchetti arrivano al kernel con un
 437 certo indirizzo ed una certa porta di destinazione, il kernel controlla se
 438 corrispondono ad un socket che è stato \textsl{legato} ad essi con
 439 \func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
 440 socket, così che il programma possa leggerlo, altrimenti risponderà alla
 441 macchina che ha inviato il pacchetto con un messaggio ICMP di tipo
 442 \textit{port unreachable}.
 443
 444 Una volta completata la fase di inizializzazione inizia il corpo principale
 445 (\texttt{\small 24--44}) del server, mantenuto all'interno di un ciclo
 446 infinito in cui si trattano le richieste. Il ciclo inizia (\texttt{\small 26})
 447 con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
 448 inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
 449 volte che un pacchetto viene inviato al server, in modo da poter ricavare da
 450 esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
 451 questo motivo in questo caso (al contrario di quanto fatto in
 452 \figref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
 453 \var{addr} e \var{len} alla funzione.  Dopo aver controllato (\texttt{\small
 454   27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
 455 qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
 456 l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
 457 caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
 458 richiesta (questa sezione è identica a quella del server TCP illustrato in
 459 \figref{fig:TCP_daytime_cunc_server_code}).
 460
 461 Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
 462 (\texttt{\small 36}) e costruire (\texttt{\small 37}) la stringa di risposta,
 463 che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
 464 avendo al solito cura di controllare (\texttt{\small 40--42}) lo stato di
 465 uscita della funzione e trattando opportunamente la condizione di errore.
 466
 467 Si noti come per le peculiarità del protocollo si sia utilizzato un server
 468 iterativo, che processa le richieste una alla volta via via che gli arrivano.
 469 Questa è una caratteristica comune dei server UDP, conseguenza diretta del
 470 fatto che non esiste il concetto di connessione, per cui non c'è la necessità
 471 di trattare separatamente le singole connessioni. Questo significa anche che è
 472 il kernel a gestire la possibilità di richieste multiple in contemporanea;
 473 quello che succede è semplicemente che il kernel accumula in un buffer in
 474 ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
 475 volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
 476 compito del server distribuire le risposte sulla base dell'indirizzo da cui
 477 provengono le richieste.
 478
 479
 480
 481
 482 \subsection{L'uso della funzione \func{connect} con i socket UDP}
 483 \label{sec:UDP_connect}
 484
 485 Come illustrato in \secref{sec:UDP_characteristics} essendo i socket UDP privi
 486 di connessione non è necessario per i client usare \func{connect} prima di
 487 iniziare una comunicazione con un server.
 488
 489
 490
 491 \section{I socket \textit{Unix domain}}
 492 \label{sec:unix_socket}
 493
 494 Benché i socket Unix domain non siano strettamente attinenti alla rete, in
 495 quanto definiscono una interfaccia di comunicazione locale alla singola
 496 macchina, li tratteremo comunque in questa sezione in quanto la loro
 497 interfaccia è comunque basata sulla più generale interfaccia dei socket.
 498
 499
 500
 501
 502
 503 %%% Local Variables:
 504 %%% mode: latex
 505 %%% TeX-master: "gapil"
 506 %%% End: