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}\footnote{per
  90   ottenere il risultato mostrato occorre usare le opzioni \texttt{-anu}.} per
  91 verificare quali socket sono in ascolto:
  92 \begin{verbatim}
  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 usabili in generale per la trasmissione di dati
 127 attraverso qualunque tipo di socket. Esse hanno la caratteristica di prevedere
 128 tre argomenti aggiuntivi attraveso i quali è possibile specificare la
 129 destinazione o l'origine dei dati trasmessi. La prima di queste funzioni è
 130 \funcd{sendto} ed il suo prototipo\footnote{il prototipo illustrato è quello
 131   utilizzato dalle \acr{glibc}, che seguono le \textit{Single Unix
 132     Specification}, l'argomento \param{flags} era di tipo \type{int} nei vari
 133   BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva usato un
 134   \type{unsigned int}; l'argomento \param{len} era \type{int} nei vari BSD4.*
 135   e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine l'argomento
 136   \param{tolen} era \type{int} nei vari BSD4.* nelle \acr{libc4} e nelle
 137   \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 ed il buffer
 179 \param{buf} (e relativa lunghezza \param{len}) che contiene i dati da inviare.
 180 Come per \func{write} la funzione ritorna il numero di byte inviati; nel caso
 181 di UDP però questo deve sempre corrispondere alla dimensione totale
 182 specificata da \param{len} in quanto i dati vengono sempre inviati in forma di
 183 pacchetto e non possono essere spezzati in invii successivi. Qualora non ci
 184 sia spazio nel buffer di uscita la funzione si blocca (a meno di non avere
 185 aperto il socket in modalità non bloccante), se invece non è possibile inviare
 186 il messaggio all'interno di un unico pacchetto essa fallisce con l'errore di
 187 \errcode{EMSGSIZE}.
 188
 189 I due argomenti \param{to} e \param{tolen} servono a specificare la
 190 destinazione del messaggio da inviare, e prendono l'indirizzo di quest'ultima,
 191 nella stessa forma in cui lo si specificherebbe per \func{connect}: \param{to}
 192 deve cioè contenere l'indirizzo IP e la porta di destinazione cui si vogliono
 193 inviare i dati e \param{tolen} la relativa dimensione.
 194
 195 Se il socket è di un tipo che prevede le connessioni, questo deve essere già
 196 connesso prima di eseguire la funzione (altrimenti si avrà un errore di
 197 \errcode{ENOTCONN}) ed inoltre questi due ultimi argomenti devono essere
 198 inizializzati rispettivamente a \const{NULL} e 0 (di solito vengono ignorati,
 199 ma si potrebbe ricevere altrimenti anche un errore di \errcode{EISCONN}).
 200
 201 Infine l'argomento \param{flags} è un intero usato come maschera binaria che
 202 permette di impostare una serie di modalità di funzionamento della
 203 comunicazione attraverso il socket (come \const{MSG\_NOSIGNAL} che impedisce
 204 l'invio del segnale \const{SIGPIPE} quando si è già chiuso il capo locale
 205 della connessione). Torneremo con maggiori dettagli sul significato di questo
 206 argomento in \secref{sec:xxx_sendmsg}, per il momento ci si può limitare ad
 207 usare sempre un valore nullo.
 208
 209 La seconda funzione utilizzata nella comunicazione fra socket UDP è
 210 \funcd{recvfrom} che serve invece a ricevere i dati inviati da un altro
 211 socket, il suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che
 212   seguono le \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4}
 213   e le \acr{libc5} usano un \type{int} come valore di ritorno; per gli
 214   argomenti \param{flags} e \param{len} vale quanto detto a proposito di
 215   \func{sendto}; infine l'argomento \param{fromlen} è \type{int} per i vari
 216   BSD4.*, le \acr{libc4} e le \acr{libc5}.} è:
 217 \begin{functions}
 218   \headdecl{sys/types.h}
 219   \headdecl{sys/socket.h}
 220
 221   \funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
 222     flags, const struct sockaddr *from, socklen\_t *fromlen)}
 223
 224   Riceve un messaggio ad un altro socket.
 225
 226   \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
 227     successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
 228     valore:
 229   \begin{errlist}
 230   \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
 231     l'operazione richede che la funzione si blocchi, oppure si è impostato un
 232     timeout in ricezione e questo è scaduto.
 233   \item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato
 234     la connessione (in genere perché il relativo servizio non è disponibile).
 235   \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
 236     la connessione.
 237   \end{errlist}
 238   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
 239   \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
 240   ai protocolli utilizzati.}
 241 \end{functions}
 242
 243 Come per \func{sendto} i primi tre argomenti sono identici agli analoghi di
 244 \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel
 245 buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
 246 o \textit{stream}) inoltre i byte in eccesso che non sono stati letti possono
 247 rispettivamente andare persi o restare disponibili per una lettura successiva.
 248 Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
 249 il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
 250 \errcode{EAGAIN}.  Qualora \param{len} ecceda la dimensione del pacchetto la
 251 funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
 252 comunque il numero di byte letti.
 253
 254 I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
 255 l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
 256 opportunamente inizializzati con i puntatori alle variabili dove quest'ultimo
 257 e la sua lunghezza saranno memorizzati (si noti che \param{fromlen} è un
 258 valore intero ottenuto come \textit{value return argoment}).  Se non si è
 259 interessati a questa informazione, entrambi gli argomenti devono essere
 260 inizializzati al valore \const{NULL}.
 261
 262 Un'altra differenza fondamentale di queste funzioni rispetto alle usuali
 263 \func{read} e \func{write} che abbiamo usato con i socket TCP è che in questo
 264 caso è perfettamente legale inviare con \func{sendto} un pacchetto vuoto (che
 265 nel caso conterrà solo le intestazioni di IP e di UDP), scrivendo 0 byte. Allo
 266 stesso è possibile ricevere con \func{recvfrom} un valore di ritorno di 0
 267 byte, senza che questo possa configurarsi come una chiusura della
 268 connessione\footnote{dato che la connessione non esiste, non ha senso parlare
 269   di chiusura della connessione, pertanto con i socket UDP non è necessario
 270   usare \func{close} per terminare la cominicazione.} o come una cessazione
 271 delle comunicazioni.
 272
 273
 274 \subsection{Un client elementare}
 275 \label{sec:UDP_simple_server}
 276
 277 Vediamo allora come implementare un primo server elementare su UDP; ricalcando
 278 quanto fatto nel caso dei socket TCP prenderemo come primo esempio l'uso del
 279 servizio \textit{time}, utilizzanto questa volta UDP.
 280
 281
 282
 283
 284 \subsection{L'uso della funzione \func{connect} con i socket UDP}
 285 \label{sec:UDP_connect}
 286
 287 Come illustrato in \secref{sec:UDP_characteristics} essendo i socket UDP privi
 288 di connessione non è necessario per i client usare \func{connect} prima di
 289 iniziare una comunicazione con un server.
 290
 291
 292
 293 \section{I socket \textit{Unix domain}}
 294 \label{sec:unix_socket}
 295
 296 Benché i socket Unix domain non siano strattamente attinenti alla rete, in
 297 quanto definiscono una interfaccia di comunicazione locale alla singola
 298 macchina, li tratteremo comunque in questa sezione in quanto la loro
 299 interfaccia è comunque basata sulla più generale interfaccia dei socket.
 300
 301
 302
 303
 304 %%% Local Variables:
 305 %%% mode: latex
 306 %%% TeX-master: "gapil"
 307 %%% End: