socket.tex

   1 \chapter{Socket}
   2 \label{cha:socket}
   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.
   8
   9 La creazione di un socket restituisce un file descriptor con un comportamento
  10 analogo a quello di una pipe ma a differenza di questa e degli altri
  11 meccanismi esaminati nel capitolo \ref{cha:ipc} i socket non sono limitati
  12 alla comunicazione fra processi che girano sulla stessa macchina ma possono
  13 effettuare la comunicazione anche attraverso la rete.
  14
  15 I socket infatti sono la principale API (\textit{Application Program
  16   Interface}) usata nella programmazione di rete. La loro origine risale al
  17 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
  18 sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
  19 siano state sviluppate interfacce alternative, originate dai sistemi SYSV,
  20 come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
  21 diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
  22 flessibilità).
  23
  24 La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
  25 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
  26 solo con la suite dei protocolli TCP/IP, che sarà comunque quella di cui
  27 tratteremo in maniera più estesa.
  28
  29
  30 \section{Concetti base}
  31 \label{sec:sock_gen}
  32
  33 Per capire il funzionamento dei socket occorre avere presente il funzionamento
  34 dei protocolli di rete (vedi \ref{cha:network}), ma l'interfaccia è del tutto
  35 generale e benché le problematiche (e quindi le modalità di risolvere i
  36 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
  37 usato, le funzioni da usare restano le stesse.
  38
  39 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
  40 inutile, in quanto il comportamento di quest'ultima e le problematiche da
  41 affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione
  42 usato.  La scelta di questo stile va infatti ad incidere sulla semantica che
  43 verrà utilizzata a livello utente per gestire la comunicazione (su come
  44 inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
  45 utilizzate.
  46
  47 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
  48 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
  49 comunicazione considerano i dati come una sequenza continua di bytes, altri
  50 invece li raggruppano in blocchi (i pacchetti).
  51
  52 Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
  53 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
  54 inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
  55
  56 Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
  57 avviene, in certi casi essa può essere condotta con una connessione diretta
  58 con un solo partner come per una telefonata; altri casi possono prevedere una
  59 comunicazione come per lettera, in cui si scrive l'indirizzo su ogni
  60 pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
  61 radio, in cui i pacchetti vengono emessi su appositi ``canali'' dove chiunque
  62 si collega possa riceverli.
  63
  64 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
  65 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
  66 gestire la perdita o il rimescolamento dei dati.
  67
  68 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
  69 tipi di socket, che vengono classificati raggruppandoli in quelli che si
  70 chiamano \textsl{domini} (\textit{domains}).  La scelta di un dominio equivale
  71 in sostanza alla scelta di una famiglia di protocolli. Ciascun dominio ha un
  72 suo nome simbolico che convenzionalmente inizia con \texttt{PF\_} (da
  73 \textit{Protocol Family}, altro nome con cui si indicano i domini).
  74
  75 A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
  76 \texttt{AF\_} da \textit{Address Family}, nome che useremo anche noi; le man
  77 pages di linux si riferiscono a questi anche come \textit{name space}, (nome
  78 che però il manuale della glibc riserva ai domini) e che identifica il formato
  79 degli indirizzi usati in quel dominio.
  80
  81 I domini (e i relativi nomi simbolici) sono definiti dall'header
  82 \textit{socket.h}. In linux sono disponibili le famiglie di protocolli
  83 riportate in \ntab.
  84
  85 \begin{table}[htb]
  86   \centering
  87   \begin{tabular}[c]{lll}
  88        Nome               & Utilizzo                       & Man page   \\
  89        PF\_UNIX,PF\_LOCAL & Local communication            & unix(7)    \\
  90        PF\_INET           & IPv4 Internet protocols        & ip(7)      \\
  91        PF\_INET6          & IPv6 Internet protocols        &            \\
  92        PF\_IPX            & IPX - Novell protocols         &            \\
  93        PF\_NETLINK        & Kernel user interface device   & netlink(7) \\
  94        PF\_X25            & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\
  95        PF\_AX25           & Amateur radio AX.25 protocol   &            \\
  96        PF\_ATMPVC         & Access to raw ATM PVCs         &            \\
  97        PF\_APPLETALK      & Appletalk                      & ddp(7)     \\
  98        PF\_PACKET         & Low level packet interface     & packet(7)  \\
  99   \end{tabular}
 100   \caption{Famiglie di protocolli definiti in linux}
 101   \label{tab:net_pf_names}
 102 \end{table}
 103
 104 La scelta di un dominio non comporta però la scelta dello stile di
 105 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 106 utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
 107 scegliere lo stile di comunicazione indicando il tipo di socket; linux e le
 108 glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
 109 glibc chiama \textit{styles}) definiti come \texttt{int} in \texttt{socket.h}:
 110
 111 \begin{list}{}{}
 112 \item \texttt{SOCK\_STREAM} Provvede un canale di trasmissione dati
 113   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 114   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
 115   byte (da cui il nome \textit{stream}). Vedi \ref{sec:sock_stream}.
 116 \item \texttt{SOCK\_DGRAM} Viene usato per mandare pacchetti di lunghezza
 117   massima fissata (\textit{datagram}) indirizzati singolarmente, senza
 118   connessione e in maniera non affidabile. È l'opposto del precedente. Vedi
 119   \ref{sec:sock_dgram}.
 120 \item \texttt{SOCK\_SEQPACKET} Provvede un canale di trasmissione di dati
 121   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 122   altro socket. I dati possono solo essere trasmessi e letti per pacchetti (di
 123   dimensione massima fissata).
 124 \item \texttt{SOCK\_RAW} Provvede l'accesso a basso livello ai protocolli di
 125   rete e alle varie interfacce. I normali programmi di comunicazione non
 126   devono usarlo.
 127 \item \texttt{SOCK\_RDM} Provvede un canale di trasmissione di pacchetti
 128   affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
 129 \item \texttt{SOCK\_PACKET} Obsoleto, non deve essere usato.
 130 \end{list}
 131
 132
 133
 134
 135