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 socket più comuni}
  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,
  17
  18
  19 \section{I socket UDP}
  20 \label{sec:UDP_socket}
  21
  22 Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
  23 socket UDP; protocolli diffusi come NFS o il DNS usano principalmente questo
  24 tipo di socket. Tratteremo in questa sezione le loro caratteristiche
  25 principali e le modalità per il loro utilizzo.
  26
  27
  28 \subsection{Le caratteristiche di un socket UDP}
  29 \label{sec:UDP_characteristics}
  30
  31 Come illustrato in \secref{sec:net_udp} UDP è un protocollo molto semplice che
  32 non supporta le connessioni e non è affidabile: esso si appoggia direttamente
  33 sopra IP (per i dettagli sul protocollo si veda \secref{sec:udp_protocol}).  I
  34 dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
  35 effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
  36 vantaggio del protocollo è la velocità, non è necessario trasmettere le
  37 informazioni di controllo ed il risultato è una trasmissione di dati più
  38 veloce ed immediata.
  39
  40 Questo significa che a differenza dei socket TCP i socket UDP non supportano
  41 una comunicazione di tipo \textit{stream} in cui si ha a disposizione un
  42 flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
  43 una comunicazione di tipo \textit{datagram}, in cui i dati arrivano in singoli
  44 blocchi che devono essere letti integralmente.
  45
  46 Questo diverso comportamento significa anche che i socket UDP, pur
  47 appartenendo alla famiglia \const{PF\_INET}\footnote{o \const{PF\_INET6}
  48   qualora si usasse invece il protocollo IPv6, che pure supporta UDP.} devono
  49 essere aperti quando si usa la funzione \func{socket} (si riveda quanto
  50 illustrato a suo tempo in \tabref{tab:sock_sock_valid_combinations})
  51 utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
  52
  53 Questa differenza comporta ovviamente che anche le modalità con cui si usano i
  54 socket UDP sono completamente diverse rispetto ai socket TCP, ed in
  55 particolare non esistendo il concetto di connessione non esiste il meccanismo
  56 del \textit{three way handshake} nè quello degli stati del protocollo. In
  57 realtà tutto quello che avviene nella comunicazione attraverso dei socket UDP
  58 è la trasmissione di un pacchetto da un client ad un server o viceversa,
  59 secondo lo schema illustrato in \figref{fig:UDP_packet-exchange}.
  60
  61 \begin{figure}[htb]
  62   \centering
  63   \includegraphics[width=10cm]{img/udp_connection}
  64   \caption{Lo schema di interscambio dei pacchetti per una comunicazione via
  65      UDP.}
  66   \label{fig:UDP_packet-exchange}
  67 \end{figure}
  68
  69 Come illustrato in \figref{fig:UDP_packet-exchange} la struttura generica di
  70 un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
  71 per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
  72 TCP: non essendovi il concetto di connessione le funzioni \func{listen} ed
  73 \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
  74 dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
  75 eventuale risposta sarà inviata con la funzione \func{sendto}.
  76
  77 Da parte del client invece, una volta creato il socket non sarà necessario
  78 connettersi con \func{connect} (anche se, come vedremo in
  79 \secref{sec:UDP_connect}, è possibile usare questa funzione, con un
  80 significato comunque diverso) ma si potrà effettuare direttamente una
  81 richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
  82 leggere una eventuale risposta con la funzione \func{recvfrom}.
  83
  84 Anche se UDP è completamente diverso rispetto a TCP resta identica la
  85 possibilità di gestire più canali di comunicazione fra due macchine
  86 utilizzando le porte. In questo caso il server dovrà usare comunque la
  87 funzione \func{bind} per scegliere la porta su cui ricevere i dati, e come nel
  88 caso dei socket TCP si potrà usare il comando \cmd{netstat}\footnote{per
  89   ottenere il risultato mostrato occorre usare le opzioni \texttt{-anu}.} per
  90 verificare quali socket sono in ascolto:
  91 \begin{verbatim}
  92 Active Internet connections (servers and established)
  93 Proto Recv-Q Send-Q Local Address           Foreign Address         State
  94 udp        0      0 0.0.0.0:32768           0.0.0.0:*
  95 udp        0      0 192.168.1.2:53          0.0.0.0:*
  96 udp        0      0 127.0.0.1:53            0.0.0.0:*
  97 udp        0      0 0.0.0.0:67              0.0.0.0:*
  98 \end{verbatim}
  99 in questo caso abbiamo attivi il DNS (sulla porta 53, e sulla 32768 per la
 100 connessione di controllo del server \cmd{named}) ed un server DHCP (sulla
 101 porta 67).
 102
 103 Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
 104 socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico
 105 non si avranno indicazioni delle connessioni attive, proprio perché non esiste
 106 niente di simile per i socket UDP, il kernel si limita infatti a ricevere i
 107 pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
 108 destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
 109   unreachable} qualora non vi sia nessun processo in ascolto.
 110
 111
 112 \subsection{Le funzioni \func{sendto} e \func{recvfrom}}
 113 \label{sec:UDP_sendto_recvfrom}
 114
 115 Come accennato in \secref{sec:UDP_characteristics} le due funzioni principali
 116 usate per la trasmissione di dati attraverso i socket UDP, sono \func{sendto}
 117 e \func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che
 118 non esistendo con UDP il concetto di connessione, non si ha neanche a
 119 disposizione un \textsl{socket connesso} su cui sia possibile usare
 120 direttamente \func{read} e \func{write} avendo già stabilito (grazie alla
 121 chiamata ad \func{accept} che lo associa ad una connessione) quali sono
 122 sorgente e destinazione dei dati.
 123
 124 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 125 funzioni, che sono comunque usabili in generale per la trasmissione di dati
 126 attraverso qualunque tipo di socket, dato che esse hanno la caratteristica di
 127 provvedere tre argomenti aggiuntivi che consentono di specificare destinazione
 128 o origine dei dati trasmessi. La prima delle due funzioni è \funcd{sendto} ed
 129 il suo prototipo\footnote{il prototipo illustrato è quello utilizzato dalle
 130   \acr{glibc}, che seguono le \textit{Single Unix Specification}, l'argomento
 131   \param{flags} era di tipo \type{int} nei vari BSD4.*, mentre nelle
 132   \acr{libc4} e \acr{libc5} veniva usato un \type{unsigned int}; l'argomento
 133   \param{len} era \type{int} nei vari BSD4.* e nelle \acr{libc4}, ma
 134   \type{size\_t} nelle \acr{libc5}; infine l'argomento \param{tolen} era
 135   \type{int} nei vari BSD4.* nelle \acr{libc4} e nelle \acr{libc5}.} è:
 136 \begin{functions}
 137   \headdecl{sys/types.h}
 138   \headdecl{sys/socket.h}
 139
 140   \funcdecl{ssize\_t sendto(int sockfd, const void *buf, size\_t len, int
 141     flags, const struct sockaddr *to, socklen\_t tolen)}
 142
 143   Trasmette un messaggio ad un altro socket.
 144
 145   \bodydesc{La funzione restituisce il numero di caratteri inviati in caso di
 146     successo e -1 per un errore; nel qual caso \var{errno} viene impostata al
 147     rispettivo codice di errore:
 148   \begin{errlist}
 149   \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
 150     l'operazione richede che la funzione si blocchi.
 151   \item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la
 152     conessione.
 153   \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
 154     specificato un indirizzo di destinazione.
 155   \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
 156     destinatario.
 157   \item[\errcode{EMSGSIZE}] il tipo di socket richiede l'invio dei dati in un
 158     blocco unico, ma la dimensione del messaggio lo rende impossibile.
 159   \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
 160     norma Linux non usa questo messaggio ma scarta silenziosamente i
 161     pacchetti).
 162   \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
 163     una destinazione.
 164   \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
 165     il tipo di socket usato.
 166   \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
 167     riceverà anche un segnale di \const{SIGPIPE}, a meno di non aver impostato
 168     \const{MSG\_NOSIGNAL} in \param{flags}.
 169   \end{errlist}
 170   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
 171   \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
 172   ai protocolli utilizzati.}
 173 \end{functions}
 174
 175 I primi tre argomenti sono identici a quelli della funzione \func{write} e
 176 specificano il socket \param{sockfd} a cui si fa riferimento ed il buffer
 177 \param{buf} (e relativa lunghezza \param{len}) che contiene i dati da inviare.
 178 Come per \func{write} la funzione ritorna il numero di byte inviati; nel caso
 179 di UDP però questo deve sempre corrispondere alla dimensione totale
 180 specificata da \param{len} in quanto i dati vengono sempre inviati in forma di
 181 pacchetto e non possono essere spezzati in invii successivi. Qualora non ci
 182 sia spazio nel buffer di uscita la funzione si blocca (a meno di non avere
 183 aperto il socket in modalità non bloccante), se invece non è possibile inviare
 184 il messaggio all'interno di un unico pacchetto essa fallisce con l'errore di
 185 \errcode{EMSGSIZE}.
 186
 187 I due argomenti \param{to} e \param{tolen} servono a specificare la
 188 destinazione del messaggio da inviare, e prendono l'indirizzo di quest'ultima,
 189 nella stessa forma in cui lo si specificherebbe per \func{connect}: \param{to}
 190 deve cioè contere l'indirizzo IP e la porta di destinazione cui si vogliono
 191 inviare i dati e \param{tolen} la relativa dimensione.
 192
 193 Se il socket è di un tipo che prevede le connessioni, questo deve essere già
 194 connesso prima di eseguire la funzione (altrimenti si avrà un errore di
 195 \errcode{ENOTCONN}) ed inoltre questi due ultimi argomenti devono essere
 196 inizializzati rispettivamente a \const{NULL} e 0 (di solito vengono ignorati,
 197 ma si potrebbe ricevere altrimenti anche un errore di \errcode{EISCONN}).
 198
 199 Infine l'argomento \param{flags} è un intero usato come maschera binaria che
 200 permette di impostare una serie di modalità di funzionamento della
 201 comunicazione attraverso il socket (come \const{MSG\_NOSIGNAL} che impedisce
 202 l'invio del segnale \const{SIGPIPE} quando si è già chiuso il capo locale
 203 della connessione). Torneremo con maggiori dettagli sul significato di questo
 204 argomento in \secref{sec:xxx_sendmsg}, per il momento ci si può limitare ad
 205 usare sempre un valore nullo.
 206
 207 La seconda funzione utilizzata nella comunicazione fra socket UDP è
 208 \funcd{recvfrom} che serve invece a ricevere i dati inviati da un altro
 209 socket, il suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che
 210   seguono le \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4}
 211   e le \acr{libc5} usano un \type{int} come valore di ritorno; per gli
 212   argomenti \param{flags} e \param{len} vale quanto detto a proposito di
 213   \func{sendto}; infine l'argomento \param{fromlen} è \type{int} per i vari
 214   BSD4.*, le \acr{libc4} e le \acr{libc5}.} è:
 215 \begin{functions}
 216   \headdecl{sys/types.h}
 217   \headdecl{sys/socket.h}
 218
 219   \funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
 220     flags, const struct sockaddr *from, socklen\_t *fromlen)}
 221
 222   Riceve un messaggio ad un altro socket.
 223
 224   \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
 225     successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
 226     valore:
 227   \begin{errlist}
 228   \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
 229     l'operazione richede che la funzione si blocchi, oppure si è impostato un
 230     timeout in ricezione e questo è scaduto.
 231   \item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato
 232     la connessione (in genere perché il relativo servizio non è disponibile).
 233   \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
 234     la connessione.
 235   \end{errlist}
 236   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
 237   \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
 238   ai protocolli utilizzati.}
 239 \end{functions}
 240
 241 Come per \func{sendto} i primi tre argomenti sono identici agli analoghi di
 242 \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel
 243 buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
 244 o \textit{stream}) inoltre i byte in eccesso che non sono stati letti possono
 245 rispettivamente andare persi o restare disponibili per una lettura
 246 successiva.
 247
 248
 249
 250
 251
 252 \subsection{L'uso della funzione \func{connect} con i socket UDP}
 253 \label{sec:UDP_connect}
 254
 255 Come illustrato in \secref{sec:UDP_characteristics} essendo i socket UDP privi
 256 di connessione non è necessario per i client usare \func{connect} prima di
 257 iniziare una comunicazione con un server.
 258
 259
 260
 261 \section{I socket \textit{Unix domain}}
 262 \label{sec:unix_socket}
 263
 264 Benché i socket Unix domain non siano strattamente attinenti alla rete, in
 265 quanto definiscono una interfaccia di comunicazione locale alla singola
 266 macchina, li tratteremo comunque in questa sezione in quanto la loro
 267 interfaccia è comunque basata sulla più generale interfaccia dei socket.
 268
 269
 270
 271
 272 %%% Local Variables:
 273 %%% mode: latex
 274 %%% TeX-master: "gapil"
 275 %%% End: