socket.tex

   1 \chapter{Introduzione ai socket}
   2 \label{cha:socket_intro}
   3
   4 Il \textit{socket} (traducibile liberamente come \textsl{manicotto}) è uno dei
   5 principali meccanismi di comunicazione fra programmi utilizzato in ambito unix
   6 (e non solo). Il socket costituisce in sostanza un canale di comunicazione fra
   7 due processi su cui si possono leggere e scrivere dati analogo a quello di una
   8 pipe ma a differenza di questa e degli altri meccanismi esaminati nel capitolo
   9 \ref{cha:IPC} i socket non sono limitati alla comunicazione fra processi che
  10 girano sulla stessa macchina ma possono effettuare la comunicazione anche
  11 attraverso la rete.
  12
  13 Quella dei socket costituisce infatti la principale API (\textit{Application
  14   Program Interface}) usata nella programmazione di rete.  La loro origine
  15 risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
  16 sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
  17 siano state sviluppate interfacce alternative, originate dai sistemi SYSV,
  18 come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
  19 diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
  20 flessibilità).
  21
  22 La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
  23 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
  24 solo con la suite dei protocolli TCP/IP, che sarà comunque quella di cui
  25 tratteremo in maniera più estesa.
  26
  27
  28 \section{Concetti base}
  29 \label{sec:sock_gen}
  30
  31 Per capire il funzionamento dei socket occorre avere presente il funzionamento
  32 dei protocolli di rete (vedi \ref{cha:network}), ma l'interfaccia è del tutto
  33 generale e benché le problematiche (e quindi le modalità di risolvere i
  34 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
  35 usato, le funzioni da usare restano le stesse.
  36
  37 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
  38 inutile, in quanto il comportamento di quest'ultima e le problematiche da
  39 affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione
  40 usato.  La scelta di questo stile va infatti ad incidere sulla semantica che
  41 verrà utilizzata a livello utente per gestire la comunicazione (su come
  42 inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
  43 utilizzate.
  44
  45 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
  46 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
  47 comunicazione considerano i dati come una sequenza continua di bytes, altri
  48 invece li raggruppano in blocchi (i pacchetti).
  49
  50 Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
  51 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
  52 inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
  53
  54 Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
  55 avviene, in certi casi essa può essere condotta con una connessione diretta
  56 con un solo partner come per una telefonata; altri casi possono prevedere una
  57 comunicazione come per lettera, in cui si scrive l'indirizzo su ogni
  58 pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
  59 radio, in cui i pacchetti vengono emessi su appositi ``canali'' dove chiunque
  60 si collega possa riceverli.
  61
  62 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
  63 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
  64 gestire la perdita o il rimescolamento dei dati.
  65
  66
  67 \section{La funzione \texttt{socket}}
  68 \label{sec:sock_socket}
  69
  70 La creazione di un socket avviene attraverso l'uso della funzione
  71 \texttt{socket} questa restituisce un \textit{socket descriptor} (un valore
  72 intero non negativo) che come gli analoghi file descriptor di files e alle
  73 pipes serve come riferimento al socket; in sostanza è l'indice nella tabella
  74 dei file che contiene i puntatori alle opportune strutture usate dal kernel ed
  75 allocate per ogni processo, (la stessa usata per i files e le pipes [NdA
  76 verificare!]).
  77
  78 Il prototipo della funzione è definito nell'header \texttt{sys/socket.h}, la
  79 funzione prende tre parametri, il dominio del socket (che definisce la
  80 famiglia di protocolli, vedi \ref{sec:sock_domain}), il tipo di socket (che
  81 definisce lo stile di comunicazione vedi \ref{sec:sock_type}) e il protocollo;
  82 in genere quest'ultimo è indicato implicitamente dal tipo di socket, per cui
  83 viene messo a zero (con l'eccezione dei \textit{raw socket}).
  84
  85 \begin{itemize}
  86 \item \texttt{int socket(int domain, int type, int protocol)}
  87
  88   La funzione restituisce un intero positivo se riesce, e -1 se fallisce, in
  89   quest'ultimo caso la variabile \texttt{errno} è settata con i seguenti
  90   codici di errore:
  91
  92   \begin{itemize}
  93   \item \texttt{EPROTONOSUPPORT} Il tipo di socket o il protocollo scelto non
  94     sono supportati nel dominio.
  95   \item \texttt{ENFILE} Il kernel non ha memoria sufficiente a creare una
  96     nuova strutture per il socket.
  97   \item \texttt{EMFILE} Si è ecceduta la tabella dei file.
  98   \item \texttt{EACCES} Non si hanno privilegi per creare un socket nel
  99     dominio o con il protocollo specificato.
 100   \item \texttt{EINVAL} Protocollo sconosciuto o dominio non disponibile.
 101   \item \texttt{ENOBUFS} o \texttt{ENOMEM} Non c'è sufficiente memoria per
 102     creare il socket.
 103   \end{itemize}
 104 \end{itemize}
 105
 106 Si noti che la creazione del socket non comporta nulla riguardo
 107 all'indicazione degli indirizzi remoti o locali attraverso i quali si vuole
 108 effettuare la comunicazione.
 109
 110 \subsection{Il dominio, o \textit{protocol family}}
 111 \label{sec:sock_domain}
 112
 113 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
 114 tipi di socket, che vengono classificati raggruppandoli in quelli che si
 115 chiamano \textsl{domini} (\textit{domains}).  La scelta di un dominio equivale
 116 in sostanza alla scelta di una famiglia di protocolli. Ciascun dominio ha un
 117 suo nome simbolico che convenzionalmente inizia con \texttt{PF\_} (da
 118 \textit{Protocol Family}, altro nome con cui si indicano i domini).
 119
 120 A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
 121 \texttt{AF\_} da \textit{Address Family}, e che identifica il formato degli
 122 indirizzi usati in quel dominio; le man pages di linux si riferiscono a questi
 123 anche come \textit{name space}, (nome che però il manuale della glibc riserva
 124 ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
 125
 126 L'idea alla base della distinzione era che una famiglia di protocolli potesse
 127 supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si
 128 sarebbe dovuto usare nella creazione dei socket e il prefisso \texttt{AF\_} in
 129 quello delle strutture degli indirizzi; questo è quanto specificato anche
 130 dallo standard POSIX1g, ma non esistono a tuttora famiglie di protocolli che
 131 supportino diverse strutture di indirizzi, per cui nella pratica questi due
 132 nomi sono equivalenti e corrispondono agli stessi valori.
 133
 134 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
 135 indirizzi sono definiti dall'header \textit{socket.h}. In linux le famiglie di
 136 protocolli disponibili sono riportate in \ntab.
 137
 138 \begin{table}[htb]
 139   \footnotesize
 140   \centering
 141   \begin{tabular}[c]{lll}
 142        Nome               & Utilizzo                       & Man page   \\
 143        PF\_UNIX,PF\_LOCAL & Local communication            & unix(7)    \\
 144        PF\_INET           & IPv4 Internet protocols        & ip(7)      \\
 145        PF\_INET6          & IPv6 Internet protocols        &            \\
 146        PF\_IPX            & IPX - Novell protocols         &            \\
 147        PF\_NETLINK        & Kernel user interface device   & netlink(7) \\
 148        PF\_X25            & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\
 149        PF\_AX25           & Amateur radio AX.25 protocol   &            \\
 150        PF\_ATMPVC         & Access to raw ATM PVCs         &            \\
 151        PF\_APPLETALK      & Appletalk                      & ddp(7)     \\
 152        PF\_PACKET         & Low level packet interface     & packet(7)  \\
 153   \end{tabular}
 154   \caption{Famiglie di protocolli definiti in linux}
 155   \label{tab:net_pf_names}
 156 \end{table}
 157
 158 Non tutte le famiglie di protocolli sono accessibili dall'utente generico,
 159 come forma di protezione infatti soltanto root può usare i protocolli di basso
 160 livello [NdA approfondire].
 161
 162
 163 \subsection{Il tipo, o stile}
 164 \label{sec:sock_type}
 165
 166 La scelta di un dominio non comporta però la scelta dello stile di
 167 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 168 utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
 169 scegliere lo stile di comunicazione indicando il tipo di socket; linux e le
 170 glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
 171 glibc chiama \textit{styles}) definiti come \texttt{int} in \texttt{socket.h}:
 172
 173 \begin{list}{}{}
 174 \item \texttt{SOCK\_STREAM} Provvede un canale di trasmissione dati
 175   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 176   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
 177   byte (da cui il nome \textit{stream}). Vedi \ref{sec:sock_stream}.
 178 \item \texttt{SOCK\_DGRAM} Viene usato per mandare pacchetti di lunghezza
 179   massima fissata (\textit{datagram}) indirizzati singolarmente, senza
 180   connessione e in maniera non affidabile. È l'opposto del precedente. Vedi
 181   \ref{sec:sock_dgram}.
 182 \item \texttt{SOCK\_SEQPACKET} Provvede un canale di trasmissione di dati
 183   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 184   altro socket. I dati possono solo essere trasmessi e letti per pacchetti (di
 185   dimensione massima fissata).
 186 \item \texttt{SOCK\_RAW} Provvede l'accesso a basso livello ai protocolli di
 187   rete e alle varie interfacce. I normali programmi di comunicazione non
 188   devono usarlo.
 189 \item \texttt{SOCK\_RDM} Provvede un canale di trasmissione di pacchetti
 190   affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
 191 \item \texttt{SOCK\_PACKET} Obsoleto, non deve essere usato.
 192 \end{list}
 193
 194
 195 Si tenga presente che non tutte le combinazioni di famiglia di protocolli e
 196 tipo di socket sono valide, in quanto non è detto che nella famiglia esista un
 197 protocollo per tutti gli stili di comunicazione indicati qui sopra. Una
 198 tabella che mostra le combianazioni valide è la seguente:
 199
 200 \begin{table}[htb]
 201   \footnotesize
 202   \centering
 203   \begin{tabular}{l|c|c|c|c|c|}
 204     &\multicolumn{1}{c}{\texttt{SOCK\_STREAM}}&
 205      \multicolumn{1}{c}{\texttt{SOCK\_DGRAM}} &
 206      \multicolumn{1}{c}{\texttt{SOCK\_RAW}} &
 207      \multicolumn{1}{c}{\texttt{SOCK\_PACKET}}&
 208      \multicolumn{1}{c}{\texttt{SOCK\_SEQPACKET}} \\
 209     \texttt{PF\_UNIX}      &  si & si  &      &     &     \\
 210     \texttt{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
 211     \texttt{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
 212     \texttt{PF\_IPX}       &  ?  &     &      &     &     \\
 213     \texttt{PF\_NETLINK}   &     &     &  si  &     &     \\
 214     \texttt{PF\_X25}       &     &     &      &     &     \\
 215     \texttt{PF\_AX25}      &     &     &      &     &     \\
 216     \texttt{PF\_ATMPVC}    &  ?  &     &      &     &     \\
 217     \texttt{PF\_APPLETALK} &  ?  &     &      &     &     \\
 218     \texttt{PF\_PACKET}    &     &     &      &     &     \\
 219   \end{tabular}
 220   \caption{Combinazioni valide di dominio e tipo di protocollo per la funzione \texttt{socket}.}
 221   \label{tab:sock_sock_valid_combinations}
 222 \end{table}
 223
 224
 225
 226 \section{Le strutture degli indirizzi}
 227 \label{sec:sock_sockaddr}
 228
 229 La gran parte dei
 230
 231
 232 \section{Le funzioni di conversione degli indirizzi}
 233 \label{sec:sock_addr_conv}
 234
 235
 236
 237
 238
 239
 240
 241
 242 \chapter{Socket TCP elementari}
 243 \label{cha:elem_TCP_sock}
 244
 245 Esamineremo in questo capitolo quanto necessario per capire come scrivere un
 246 client e un server TCP, riprendendo quanto visto in \ref{sec:net_cli_sample} e
 247 \ref{sec:net_cli_server}.
 248
 249
 250
 251 \subsection{Creazione e terminazione della connessione TCP}
 252
 253 Per capire il funzionamento delle funzioni della interfaccia dei socket che
 254 operano con TCP (le varie \texttt{connect}, \texttt{accept}, \texttt{close}
 255 che abbiamo visto negli esempi iniziali e su cui torneremo più avatni) è
 256 fodamentale capire come funziona la creazione e la conclusione di una
 257 connessione TCP.
 258
 259 \subsection{Le porte}
 260
 261