socket.tex

   1 %% socket.tex
   2 %%
   3 %% Copyright (C) 2000-2019 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 "Un preambolo",
   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
  12 \chapter{I socket}
  13 \label{cha:socket_intro}
  14
  15 In questo capitolo inizieremo a spiegare le caratteristiche salienti della
  16 principale interfaccia per la programmazione di rete, quella dei
  17 \textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
  18 tutti i sistemi operativi.
  19
  20 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
  21 come creare un socket e come collegarlo allo specifico protocollo di rete che
  22 si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
  23 teorica concluderemo il capitolo con un primo esempio di applicazione.
  24
  25 \section{Introduzione ai socket}
  26 \label{sec:sock_overview}
  27
  28 In questa sezione daremo descrizione essenziale di cosa sono i \textit{socket}
  29 e di quali sono i concetti fondamentali da tenere presente quando si ha a che
  30 fare con essi; ne illustreremo poi le caratteristiche e le differenti
  31 tipologie presenti ed infine tratteremo le modalità con cui possono essere
  32 creati.
  33
  34 \index{socket!definizione|(}
  35
  36 \subsection{Cosa sono i \textit{socket}}
  37 \label{sec:sock_socket_def}
  38
  39 I \textit{socket} (una traduzione letterale potrebbe essere \textsl{presa}, ma
  40 essendo universalmente noti come \textit{socket} utilizzeremo sempre la parola
  41 inglese) sono uno dei principali meccanismi di comunicazione utilizzato in
  42 ambito Unix, e li abbiamo brevemente incontrati in
  43 sez.~\ref{sec:ipc_socketpair}, fra i vari meccanismi di intercomunicazione fra
  44 processi.
  45
  46 Un socket costituisce in sostanza un canale di comunicazione fra due processi
  47 su cui si possono leggere e scrivere dati analogo a quello di una
  48 \textit{pipe} (vedi sez.~\ref{sec:ipc_pipes}) ma, a differenza di questa e
  49 degli altri meccanismi esaminati nel capitolo cap.~\ref{cha:IPC}, i socket non
  50 sono limitati alla comunicazione fra processi che girano sulla stessa
  51 macchina, ma possono realizzare la comunicazione anche attraverso la rete.
  52
  53 Quella dei socket costituisce infatti la principale interfaccia usata nella
  54 programmazione di rete.  La loro origine risale al 1983, quando furono
  55 introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
  56 piccole modifiche, negli anni successivi. Benché siano state sviluppate
  57 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
  58   Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
  59 di quella dei socket (né tantomeno la stessa usabilità e flessibilità) ed oggi
  60 sono praticamente dimenticate.
  61
  62 La flessibilità e la genericità dell'interfaccia inoltre consente di
  63 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
  64 solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
  65 di cui tratteremo in maniera più estesa.
  66
  67 Per capire il funzionamento dei socket occorre avere presente il funzionamento
  68 dei protocolli di rete che su utilizzeranno (ed in particolare quelli del
  69 TCP/IP già illustrati in sez.~\ref{sec:net_tpcip}), ma l'interfaccia è del
  70 tutto generale e benché le problematiche, e quindi le modalità di risolvere i
  71 problemi, siano diverse a seconda del tipo di protocollo di comunicazione
  72 usato, le funzioni da usare nella gestione dei socket restano le stesse.
  73
  74 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
  75 inutile, in quanto il comportamento di quest'ultima e le problematiche da
  76 affrontare cambiano radicalmente a seconda del tipo di comunicazione usato.
  77 La scelta di questo tipo di comunicazione (sovente anche detto \textsl{stile})
  78 va infatti ad incidere sulla semantica che verrà utilizzata a livello utente
  79 per gestire la comunicazione cioè su come inviare e ricevere i dati e sul
  80 comportamento effettivo delle funzioni utilizzate.
  81
  82 La scelta di uno \textsl{stile} dipende sia dai meccanismi disponibili, sia
  83 dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni tipi di
  84 comunicazione considerano i dati come una sequenza continua di byte, in quello
  85 che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
  86 altri invece li raggruppano in \textsl{pacchetti} (in inglese
  87 \textit{datagram}) che vengono sempre inviati in blocchi separati e non
  88 divisibili.
  89
  90 Un altro esempio delle differenze fra i diversi tipi di comunicazione concerne
  91 la possibilità che essa possa o meno perdere dati nella trasmissione, che
  92 possa o meno rispettare l'ordine in cui i dati inviati e ricevuti, o che possa
  93 accadere di inviare dei pacchetti di dati più volte (differenze che ad esempio
  94 sono presenti nel caso di utilizzo dei protocolli TCP o UDP).
  95
  96 Un terzo esempio di differenza nel tipo di comunicazione concerne il modo in
  97 cui essa avviene nei confronti dei corrispondenti, in certi casi essa può
  98 essere condotta con una connessione diretta con un solo corrispondente, come
  99 per una telefonata; altri casi possono prevedere una comunicazione come per
 100 lettera, in cui si scrive l'indirizzo su ogni pacchetto, altri ancora una
 101 comunicazione uno a molti come il \textit{broadcast} ed il \textit{multicast},
 102 in cui i pacchetti possono venire emessi su appositi ``\textsl{canali}'' dove
 103 chiunque si collega possa riceverli.
 104
 105 É chiaro che ciascuno di questi diversi aspetti è associato ad un tipo di
 106 comunicazione che comporta una modalità diversa di gestire la stessa, ad
 107 esempio se la comunicazione è inaffidabile occorrerà essere in grado di
 108 gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
 109 dovranno essere opportunamente trattati, se è uno a molti occorrerà tener
 110 conto della eventuale unidirezionalità della stessa, ecc.
 111
 112 \index{socket!definizione|)}
 113
 114
 115 \subsection{La creazione di un socket}
 116 \label{sec:sock_creation}
 117
 118 Come accennato l'interfaccia dei socket è estremamente flessibile e permette
 119 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
 120 in questa sezione vedremo come è possibile creare un socket e come specificare
 121 il tipo di comunicazione che esso deve utilizzare.
 122
 123 La creazione di un socket avviene attraverso l'uso della funzione di sistema
 124 \funcd{socket}; essa restituisce un \textit{file descriptor} (del tutto
 125 analogo a quelli che si ottengono per i file di dati e le \textit{pipe},
 126 descritti in sez.~\ref{sec:file_fd}) che serve come riferimento al socket; il
 127 suo prototipo è:
 128
 129 \begin{funcproto}{
 130 \fhead{sys/socket.h}
 131 \fdecl{int socket(int domain, int type, int protocol)}
 132 \fdesc{Apre un socket.}
 133 }
 134
 135 {La funzione ritorna un valore positivo in caso di successo e $-1$ per un
 136   errore, nel qual caso \var{errno} assumerà uno dei valori:
 137   \begin{errlist}
 138   \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
 139     dominio o con il protocollo specificato.
 140   \item[\errcode{EAFNOSUPPORT}] famiglia di indirizzi non supportata.
 141   \item[\errcode{EINVAL}] argomento \param{type} invalido.
 142   \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
 143   \item[\errcode{ENFILE}] si è raggiunto il limite massimo di file aperti.
 144   \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
 145     (può essere anche \errval{ENOMEM}).
 146   \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
 147     non sono supportati nel dominio.
 148   \end{errlist}
 149   ed inoltre a seconda del protocollo usato, potranno essere generati altri
 150   errori, che sono riportati nelle pagine di manuale relative al protocollo.}
 151 \end{funcproto}
 152
 153
 154 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
 155 (definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
 156 protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
 157 come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
 158 \param{protocol} il protocollo; in genere quest'ultimo è indicato
 159 implicitamente dal tipo di socket, per cui di norma questo valore viene messo
 160 a zero (con l'eccezione dei \textit{raw socket}).
 161
 162 % TODO: l'ultimo argomento viene usato anche dai nuovi ping socket introdotti
 163 % con il kernel 3.0, vedi anche http://lwn.net/Articles/420799/ e
 164 % http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c319b4d76b9e583a5d88d6bf190e079c4e43213d
 165
 166 Si noti che la creazione del socket si limita ad allocare le opportune
 167 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
 168 non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
 169 attraverso i quali si vuole effettuare la comunicazione. Questo significa che
 170 la funzione da sola non è in grado di fornire alcun tipo di comunicazione.
 171
 172
 173 \subsection{Il dominio dei socket}
 174 \label{sec:sock_domain}
 175
 176 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
 177 tipi di socket, che vengono classificati raggruppandoli in quelli che si
 178 chiamano \textsl{domini}.  La scelta di un dominio equivale in sostanza alla
 179 scelta di una famiglia di protocolli, e viene effettuata attraverso
 180 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
 181 suo nome simbolico che convenzionalmente è indicato da una costante che inizia
 182 per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
 183 cui si indicano i domini.
 184
 185 A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
 186 associato ad una costante, che inizia invece per \texttt{AF\_} (da
 187 \textit{address family}) che identifica il formato degli indirizzi usati in
 188 quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
 189 anche come \textit{name space}, (nome che invece il manuale della \acr{glibc}
 190 riserva a quello che noi abbiamo chiamato domini) dato che identificano il
 191 formato degli indirizzi usati in quel dominio per identificare i capi della
 192 comunicazione.
 193
 194 \begin{table}[!htb]
 195   \footnotesize
 196   \centering
 197   \begin{tabular}[c]{|l|l|l|l|}
 198        \hline
 199        \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
 200        \hline
 201        \hline
 202        \constd{AF\_UNSPEC}   & 0& Non specificato               &            \\
 203        \constd{AF\_LOCAL}    & 1& Local communication           & unix(7)    \\
 204        \constd{AF\_UNIX}, \constd{AF\_FILE}&1&Sinonimi di \const{AF\_LOCAL}& \\
 205        \constd{AF\_INET}     & 2& IPv4 Internet protocols       & ip(7)      \\
 206        \constd{AF\_AX25}     & 3& Amateur radio AX.25 protocol  &            \\
 207        \constd{AF\_IPX}      & 4& IPX - Novell protocols        &            \\
 208        \constd{AF\_APPLETALK}& 5& Appletalk                     & ddp(7)     \\
 209        \constd{AF\_NETROM}   & 6& Amateur radio NetROM          &            \\
 210        \constd{AF\_BRIDGE}   & 7& Multiprotocol bridge          &            \\
 211        \constd{AF\_ATMPVC}   & 8& Access to raw ATM PVCs        &            \\
 212        \constd{AF\_X25}      & 9& ITU-T X.25 / ISO-8208 protocol& x25(7)     \\
 213        \constd{AF\_INET6}    &10& IPv6 Internet protocols       & ipv6(7)    \\
 214        \constd{AF\_ROSE}     &11& Amateur Radio X.25 PLP        &            \\
 215        \constd{AF\_DECnet}   &12& Reserved for DECnet project   &            \\
 216        \constd{AF\_NETBEUI}  &13& Reserved for 802.2LLC project &            \\
 217        \constd{AF\_SECURITY} &14& Security callback pseudo AF   &            \\
 218        \constd{AF\_KEY}      &15& AF\_KEY key management API    &            \\
 219        \constd{AF\_NETLINK}  &16& Kernel user interface device  & netlink(7) \\
 220        \constd{AF\_ROUTE}    &16& Sinonimo di \const{AF\_NETLINK} emula BSD.&\\
 221        \constd{AF\_PACKET}   &17& Low level packet interface    & packet(7)  \\
 222        \constd{AF\_ASH}      &18& Ash                           &    \\
 223        \constd{AF\_ECONET}   &19& Acorn Econet                  &    \\
 224        \constd{AF\_ATMSVC}   &20& ATM SVCs                      &    \\
 225        \constd{AF\_RDS}      &21& RDS Sockets                   &    \\
 226        \constd{AF\_SNA}      &22& Linux SNA Project             &    \\
 227        \constd{AF\_IRDA}     &23& IRDA socket (infrarossi)      & irda(7)    \\
 228        \constd{AF\_PPPOX}    &24& PPPoX socket                  &    \\
 229        \constd{AF\_WANPIPE}  &25& Wanpipe API socket            &    \\
 230        \constd{AF\_LLC}      &26& Linux LLC                     &    \\
 231        \constd{AF\_IB}       &27&  Native InfiniBand address    &    \\
 232        \constd{AF\_MPLS}     &28& MPSL                          &    \\
 233        \constd{AF\_CAN}      &29& Controller Are Network        &    \\
 234        \constd{AF\_TIPC}     &30& TIPC sockets                  &    \\
 235        \constd{AF\_BLUETOOTH}&31& Bluetooth socket              &    \\
 236        \constd{AF\_IUCV}     &32& IUCV sockets                  &    \\
 237        \constd{AF\_RXRPC}    &33& RxRPC sockets                 &    \\
 238        \constd{AF\_ISDN}     &34& mISDN sockets                 &    \\
 239        \constd{AF\_PHONET}   &35& Phonet sockets                &    \\
 240        \constd{AF\_IEEE802154}&36& IEEE802154 sockets           &    \\
 241        \constd{AF\_CAIF}     &37& CAIF sockets                  &    \\
 242        \constd{AF\_ALG}      &38& Algorithm sockets             &    \\
 243        \constd{AF\_NFC}      &39& NFC sockets                   &    \\
 244        \constd{AF\_VSOCK}    &40& vSockets                      &    \\
 245        \constd{AF\_KCM}      &41& Kernel Connection Multiplexor &    \\
 246        \constd{AF\_QIPCRTR}  &42& Qualcomm IPC Router           &    \\
 247        \constd{AF\_SMC}      &43& smc sockets                   &    \\
 248        \hline
 249   \end{tabular}
 250   \caption{Famiglie di protocolli definiti in Linux.}
 251   \label{tab:net_pf_names}
 252 \end{table}
 253
 254 L'idea alla base della distinzione fra questi due insiemi di costanti era che
 255 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
 256 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
 257 il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi. Questo è
 258 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
 259 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
 260 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
 261 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
 262   il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
 263   e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
 264   lo stesso nome.} Qui si sono indicati i nomi con il prefisso \texttt{AF\_}
 265 seguendo la convenzione usata nelle pagine di manuale.
 266
 267 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
 268 indirizzi, sono definiti dall'\textit{header file} \headfiled{socket.h}. Un
 269 elenco, aggiornato alla versione 4.15, delle famiglie di protocolli
 270 disponibili in Linux è riportato in tab.~\ref{tab:net_pf_names}.  L'elenco
 271 indica tutti i protocolli definiti; fra questi però saranno utilizzabili solo
 272 quelli per i quali si è compilato il supporto nel kernel (o si sono caricati
 273 gli opportuni moduli), viene definita anche una costante \constd{AF\_MAX} che
 274 indica il valore massimo associabile ad un dominio.
 275
 276 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
 277 dall'utente generico, ad esempio in generale tutti i socket di tipo
 278 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
 279 di amministratore (cioè con \ids{UID} effettivo uguale a zero) o dotati della
 280 \textit{capability} \const{CAP\_NET\_RAW}.
 281
 282
 283 \subsection{Il tipo di socket}
 284 \label{sec:sock_type}
 285
 286 La scelta di un dominio non comporta però la scelta dello stile di
 287 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 288 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
 289 socket permette di scegliere lo stile di comunicazione indicando il tipo di
 290 socket con l'argomento \param{type} di \func{socket}. Linux mette a
 291 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
 292 della \acr{glibc} \cite{GlibcMan} chiama \textit{styles}) identificati dalle
 293 seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
 294   tre tipi, Linux supporta anche gli altri, come si può verificare nel file
 295   \texttt{include/linux/net.h} dei sorgenti del kernel.}
 296
 297 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
 298 \item[\constd{SOCK\_STREAM}] Provvede un canale di trasmissione dati
 299   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 300   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
 301   byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
 302   dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
 303   urgenti (o \textit{out-of-band}, vedi sez.~\ref{sec:TCP_urgent_data}).
 304 \item[\constd{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
 305   (\textit{datagram}) di lunghezza massima prefissata, indirizzati
 306   singolarmente. Non esiste una connessione e la trasmissione è effettuata in
 307   maniera non affidabile.
 308 \item[\constd{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
 309   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 310   altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
 311   massima fissata, e devono essere letti integralmente da ciascuna chiamata a
 312   \func{read}.
 313 \item[\constd{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
 314   rete e alle varie interfacce. I normali programmi di comunicazione non
 315   devono usarlo, è riservato all'uso di sistema.
 316 \item[\constd{SOCK\_RDM}] Provvede un canale di trasmissione di dati
 317   affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
 318 \item[\constd{SOCK\_PACKET}] Obsoleto, non deve essere più usato (e pertanto
 319   non ne parleremo ulteriormente).
 320 \end{basedescript}
 321
 322 A partire dal kernel 2.6.27 l'argomento \param{type} della funzione
 323 \func{socket} assume un significato ulteriore perché può essere utlizzato per
 324 impostare dei flag relativi alle caratteristiche generali del \textit{socket}
 325 non strettamente attinenti all'indicazione del tipo secondo i valori appena
 326 illustrati. Essi infatti possono essere combinati con un OR aritmetico delle
 327 ulteriori costanti:
 328 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 329 \item[\constd{SOCK\_CLOEXEC}] imposta il flag di \textit{close-on-exec} sul
 330   file descriptor del socket, ottenendo lo stesso effetto del flag
 331   \const{O\_CLOEXEC} di \func{open} (vedi tab.~\ref{tab:open_operation_flag}),
 332   di cui costituisce l'analogo.
 333
 334 \item[\constd{SOCK\_NONBLOCK}] crea il socket in modalità non-bloccante, con
 335   effetti identici ad una successiva chiamata a \func{fcntl} per impostare il
 336   flag di \const{O\_NONBLOCK} sul file descriptor (si faccia di nuovo
 337   riferimenti al significato di quest'ultimo come spiegato in
 338   tab.~\ref{tab:open_operation_flag}).
 339 \end{basedescript}
 340
 341 Si tenga presente inoltre che non tutte le combinazioni fra una famiglia di
 342 protocolli e un tipo di socket sono valide, in quanto non è detto che in una
 343 famiglia esista un protocollo per ciascuno dei diversi stili di comunicazione
 344 appena elencati.
 345
 346 \begin{table}[htb]
 347   \footnotesize
 348   \centering
 349   \begin{tabular}{|l|c|c|c|c|c|}
 350     \hline
 351     \multicolumn{1}{|c|}{\textbf{Famiglia}}&
 352     \multicolumn{5}{|c|}{\textbf{Tipo}}\\
 353     \hline
 354     \hline
 355     &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM}     &\const{SOCK\_RAW}&
 356       \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\
 357      \hline
 358     \const{AF\_UNIX}     &  si & si  &  --  & -- &  si\footnotemark \\
 359      \hline
 360     \const{AF\_LOCAL}&\multicolumn{5}{|c|}{sinonimo di \const{AF\_UNIX}}\\
 361      \hline
 362     \const{AF\_INET}      & TCP & UDP & IPv4 & --  & --  \\
 363      \hline
 364     \const{AF\_INET6}     & TCP & UDP & IPv6 & --  & -- \\
 365      \hline
 366     \const{AF\_IPX}       & --  & si  &  --  & --  & -- \\
 367      \hline
 368     \const{AF\_NETLINK}   & --  & si  &  si  & --  & -- \\
 369      \hline
 370     \const{AF\_X25}       & --  & --  &  --  & --  & si \\
 371      \hline
 372     \const{AF\_AX25}      & --  & si  &  si  & --  & si \\
 373      \hline
 374 %    \const{AF\_ATMPVC}    & --  & --  &  --  & --  & -- \\
 375 %     \hline
 376     \const{AF\_APPLETALK} & --  & si  &  si  & --  & -- \\
 377      \hline
 378     \const{AF\_PACKET}    & --  & si  &  si  & --  & -- \\
 379      \hline
 380     \const{AF\_KEY}       & --  & --  &  si  & --  & -- \\
 381      \hline
 382     \const{AF\_IRDA}      & si  & si  &  si  & --  & si \\
 383      \hline
 384     \const{AF\_NETROM}    & --  & --  &  --  & --  & si \\
 385      \hline
 386     \const{AF\_ROSE}      & --  & --  &  --  & --  & si \\
 387      \hline
 388     \const{AF\_RDS}       & --  & --  &  --  & --  & si \\
 389      \hline
 390     \const{AF\_ECONET}    & --  & si  &  --  & --  & -- \\
 391      \hline
 392   \end{tabular}
 393   \caption{Combinazioni valide di dominio e tipo di protocollo per la
 394     funzione \func{socket}.}
 395   \label{tab:sock_sock_valid_combinations}
 396 \end{table}
 397
 398 \footnotetext{supportati a partire dal kernel 2.6.4 per socket che conservano
 399   i limiti dei messaggi e li consegnano in sequenza ordinata.}
 400
 401 In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
 402 valide possibili per le principali famiglie di protocolli. Per ogni
 403 combinazione valida si è indicato il tipo di protocollo, o la parola
 404 \textsl{si} qualora il protocollo non abbia un nome definito, mentre si sono
 405 lasciate vuote le caselle per le combinazioni non supportate.
 406
 407
 408 \section{Le strutture degli indirizzi dei socket}
 409 \label{sec:sock_sockaddr}
 410
 411 Come si è visto nella creazione di un socket non si specifica nulla oltre al
 412 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
 413 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
 414 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
 415 comunicazione.
 416
 417 Gli indirizzi infatti vengono specificati attraverso apposite strutture che
 418 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
 419 la comunicazione viene effettivamente realizzata.  Ogni famiglia di protocolli
 420 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
 421 sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
 422 iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
 423 identificati dal suffisso finale, aggiunto al nome precedente.
 424
 425
 426 \subsection{La struttura generica}
 427 \label{sec:sock_sa_gen}
 428
 429 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
 430 attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
 431 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 432 nelle varie famiglie di protocolli; questo pone il problema di come passare
 433 questi puntatori, il C moderno risolve questo problema coi i puntatori
 434 generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
 435 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
 436 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
 437 è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
 438
 439 \begin{figure}[!htb]
 440   \footnotesize \centering
 441   \begin{minipage}[c]{0.80\textwidth}
 442     \includestruct{listati/sockaddr.h}
 443   \end{minipage}
 444   \caption{La struttura generica degli indirizzi dei socket
 445     \structd{sockaddr}.}
 446   \label{fig:sock_sa_gen_struct}
 447 \end{figure}
 448
 449 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
 450 prototipo un puntatore a questa struttura; per questo motivo quando si
 451 invocano dette funzioni passando l'indirizzo di un protocollo specifico
 452 occorrerà eseguire una conversione del relativo puntatore.
 453
 454 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 455 POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
 456 rispettivi file di include in cui sono definiti; la struttura è invece
 457 definita nell'include file \headfile{sys/socket.h}.
 458
 459 \begin{table}[!htb]
 460   \centering
 461   \footnotesize
 462   \begin{tabular}{|l|l|l|}
 463     \hline
 464     \multicolumn{1}{|c|}{\textbf{Tipo}}&
 465     \multicolumn{1}{|c|}{\textbf{Descrizione}}&
 466     \multicolumn{1}{|c|}{\textbf{Header}} \\
 467     \hline
 468     \hline
 469     \typed{int8\_t}   & intero a 8 bit con segno   & \headfile{sys/types.h}\\
 470     \typed{uint8\_t}  & intero a 8 bit senza segno & \headfile{sys/types.h}\\
 471     \typed{int16\_t}  & intero a 16 bit con segno  & \headfile{sys/types.h}\\
 472     \typed{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\
 473     \typed{int32\_t}  & intero a 32 bit con segno  & \headfile{sys/types.h}\\
 474     \typed{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\
 475     \hline
 476     \typed{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\
 477     \typed{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
 478     un socket& \headfile{sys/socket.h}\\
 479     \hline
 480     \typed{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
 481     \headfile{netinet/in.h}\\
 482     \typed{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
 483     \headfile{netinet/in.h}\\
 484     \hline
 485   \end{tabular}
 486   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
 487     stabilito dallo standard POSIX.1g.}
 488   \label{tab:sock_data_types}
 489 \end{table}
 490
 491 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
 492 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
 493 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
 494 non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
 495 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
 496
 497 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
 498 di fare da riferimento per il casting, per il kernel le cose sono un po'
 499 diverse, in quanto esso usa il puntatore per recuperare il campo
 500 \var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
 501 indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
 502 sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
 503 è stato mantenuto l'uso di questa struttura.
 504
 505 Se si usa una struttura \struct{sockaddr} per allocare delle variabili
 506 generiche da usare in seguito per degli indirizzi si pone il problema che
 507 niente assicura che i dati necessari per le varie famiglie di indirizzi
 508 possano rientrare nella dimensione del campo \var{sa\_data} indicata in
 509 fig.~\ref{fig:sock_sa_gen_struct}, anzi, come vedremo in
 510 sez.~\ref{sec:sock_sa_ipv6}, nel caso di indirizzi IPv6 questa non è proprio
 511 sufficiente.
 512
 513 \begin{figure}[!htb]
 514   \footnotesize \centering
 515   \begin{minipage}[c]{0.95\textwidth}
 516     \includestruct{listati/sockaddr_storage.h}
 517   \end{minipage}
 518   \caption{La struttura generica degli indirizzi dei socket
 519     \structd{sockaddr\_storage}.}
 520   \label{fig:sock_sa_storage_struct}
 521 \end{figure}
 522
 523 Per questo l'interfaccia di programmazione dei socket prevede la defizione di
 524 una speciale struttura \struct{sockaddr\_storage} illustrata in
 525 fig.~\ref{fig:sock_sa_storage_struct}, in cui di nuovo si usa il primo campo
 526 (\var{ss\_family}) per indicare il tipo di indirizzo, ed in cui i campi
 527 successivi sono utilizzati per allineare i dati al tipo di architettura
 528 hardware utilizzata, e per allocare uno spazio sufficiente ampio per contenere
 529 qualunque tipo di indirizzo supportato. Allocando questa struttura si ha la
 530 certezza di non eccedere le dimensioni qualunque sia il tipo di indirizzi che
 531 si useranno, pertanto risulta utile tutte le volte che si devono gestire in
 532 maniera generica tipi di indirizzi diversi (ad esempio IPv4 ed IPv6).
 533
 534
 535 \subsection{La struttura degli indirizzi IPv4}
 536 \label{sec:sock_sa_ipv4}
 537
 538 I socket di tipo \const{AF\_INET} vengono usati per la comunicazione
 539 attraverso Internet; la struttura per gli indirizzi per un socket Internet (se
 540 si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
 541 \headfiled{netinet/in.h} ed ha la forma mostrata in
 542 fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 543
 544 \begin{figure}[!htb]
 545   \footnotesize\centering
 546   \begin{minipage}[c]{0.80\textwidth}
 547     \includestruct{listati/sockaddr_in.h}
 548   \end{minipage}
 549   \caption{La struttura \structd{sockaddr\_in} degli indirizzi dei socket
 550     Internet (IPv4) e la struttura \structd{in\_addr} degli indirizzi IPv4.}
 551   \label{fig:sock_sa_ipv4_struct}
 552 \end{figure}
 553
 554 L'indirizzo di un socket Internet (secondo IPv4) comprende l'indirizzo
 555 Internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
 556 dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}).  Il
 557 protocollo IP di per sé non prevede numeri di porta, questi sono utilizzati
 558 solo dai protocolli di livello superiore come TCP e UDP, ma devono essere
 559 indicati qui. Inoltre questa struttura viene usata anche per i socket RAW che
 560 accedono direttamente al livello di IP, in questo caso il numero della porta
 561 deve essere impostato al numero di protocollo.
 562
 563 Il membro \var{sin\_family} deve essere sempre impostato a \constd{AF\_INET},
 564 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
 565 specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
 566 chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
 567 soltanto processi con i privilegi di amministratore (con \ids{UID} effettivo
 568 uguale a zero) o con la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}
 569 possono usare la funzione \func{bind} (che vedremo in
 570 sez.~\ref{sec:TCP_func_bind}) su queste porte.
 571
 572 Il membro \var{sin\_addr} contiene un indirizzo Internet, e viene acceduto sia
 573 come struttura (un resto di una implementazione precedente in cui questa era
 574 una \dirct{union} usata per accedere alle diverse classi di indirizzi) che
 575 direttamente come intero. In \headfile{netinet/in.h} vengono definite anche
 576 alcune costanti che identificano alcuni indirizzi speciali, riportati in
 577 tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
 578
 579 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
 580 essere specificati in quello che viene chiamato \textit{network order}, cioè
 581 con i bit ordinati in formato \textit{big endian} (vedi
 582 sez.~\ref{sec:endianness}), questo comporta la necessità di usare apposite
 583 funzioni di conversione per mantenere la portabilità del codice (vedi
 584 sez.~\ref{sec:sock_addr_func} per i dettagli del problema e le relative
 585 soluzioni).
 586
 587
 588 \subsection{La struttura degli indirizzi IPv6}
 589 \label{sec:sock_sa_ipv6}
 590
 591 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{AF\_INET6} sono
 592 sostanzialmente identici ai precedenti; la parte in cui si trovano
 593 praticamente tutte le differenze fra i due socket è quella della struttura
 594 degli indirizzi; la sua definizione, presa da \headfile{netinet/in.h}, è
 595 riportata in fig.~\ref{fig:sock_sa_ipv6_struct}.
 596
 597 \begin{figure}[!htb]
 598   \footnotesize \centering
 599   \begin{minipage}[c]{0.80\textwidth}
 600     \includestruct{listati/sockaddr_in6.h}
 601   \end{minipage}
 602   \caption{La struttura \structd{sockaddr\_in6} degli indirizzi dei socket
 603     IPv6 e la struttura \structd{in6\_addr} degli indirizzi IPv6.}
 604   \label{fig:sock_sa_ipv6_struct}
 605 \end{figure}
 606
 607 Il campo \var{sin6\_family} deve essere sempre impostato ad \constd{AF\_INET6},
 608 il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
 609 il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
 610 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
 611 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
 612 specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed
 613 il loro uso è sperimentale.
 614
 615 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
 616 espresso da un vettore di 16 byte; anche in questo caso esistono alcuni valori
 617 predediniti, ma essendo il campo un vettore di byte non è possibile assegnarli
 618 con il calore di una costante. Esistono però le variabili predefinite
 619 \var{in6addr\_any} (che indica l'indirizzo generico) e \var{in6addr\_loopback}
 620 (che indica l'indirizzo di loopback) il cui valore può essere copiato in
 621 questo campo. A queste due variabili si aggiungono le macro
 622 \macrod{IN6ADDR\_ANY\_INIT} e \macrod{IN6ADDR\_LOOPBACK\_INIT} per effettuare
 623 delle assegnazioni statiche.
 624
 625 Infine il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il
 626 kernel 2.4, per gestire alcune operazioni riguardanti il
 627 \textit{multicasting}, è supportato solo per gli indirizzi di tipo
 628 \textit{link-local} (vedi sez.~\ref{sec:IP_ipv6_unicast}) e deve contenere
 629 l'\textit{interface index} (vedi sez.~\ref{sec:sock_ioctl_netdevice}) della
 630 scheda di rete.  Si noti infine che \struct{sockaddr\_in6} ha una dimensione
 631 maggiore della struttura \struct{sockaddr} generica di
 632 fig.~\ref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non avere
 633 fatto assunzioni riguardo alla possibilità di contenere i dati nelle
 634 dimensioni di quest'ultima (per questo se necessario è opportuno usare
 635 \struct{sockaddr\_storage}).
 636
 637
 638 \subsection{La struttura degli indirizzi locali}
 639 \label{sec:sock_sa_local}
 640
 641 I socket di tipo \const{AF\_UNIX} o \const{AF\_LOCAL} vengono usati per una
 642 comunicazione fra processi che stanno sulla stessa macchina (per questo
 643 vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
 644 hanno la caratteristica ulteriore di poter essere creati anche in maniera
 645 anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
 646 sez.~\ref{sec:ipc_socketpair}).  Quando però si vuole fare riferimento
 647 esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
 648 di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
 649 fig.~\ref{fig:sock_sa_local_struct}.
 650
 651 \begin{figure}[!htb]
 652   \footnotesize \centering
 653   \begin{minipage}[c]{0.80\textwidth}
 654     \includestruct{listati/sockaddr_un.h}
 655   \end{minipage}
 656   \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
 657     locali (detti anche \textit{unix domain}) definita in
 658     \headfiled{sys/un.h}.}
 659   \label{fig:sock_sa_local_struct}
 660 \end{figure}
 661
 662 In questo caso il campo \var{sun\_family} deve essere \constd{AF\_UNIX},
 663 mentre il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due
 664 forme; può essere ``\textit{named}'' ed in tal caso deve corrispondere ad un
 665 file (di tipo socket) presente nel filesystem o essere ``\textit{abstract}''
 666 nel qual caso viene identificato da una stringa univoca in uno spazio di nomi
 667 astratto.
 668
 669 Nel primo caso l'indirizzo viene specificato in \var{sun\_path} come una
 670 stringa (terminata da uno zero) corrispondente al \textit{pathname} del file;
 671 nel secondo caso (che è specifico di Linux e non portabile) \var{sun\_path}
 672 deve iniziare con uno zero ed il nome verrà costituito dai restanti byte che
 673 verranno interpretati come stringa senza terminazione (un byte nullo non ha in
 674 questo caso nessun significato).
 675
 676 In realtà esiste una terza forma, \textit{unnamed}, che non è possibile
 677 indicare in fase di scrittura, ma che è quella che viene usata quando si legge
 678 l'indirizzo di un socket anonimo creato con \texttt{socketpair}; in tal caso
 679 la struttura restituita è di dimensione \code{sizeof(sa\_family\_t)}, quindi
 680 \var{sun\_path} non esiste e non deve essere referenziato.
 681
 682 \subsection{La struttura degli indirizzi AppleTalk}
 683 \label{sec:sock_sa_appletalk}
 684
 685 I socket di tipo \const{AF\_APPLETALK} sono usati dalla libreria
 686 \file{netatalk} per implementare la comunicazione secondo il protocollo
 687 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
 688 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
 689 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
 690 opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
 691 questo argomento principalmente per mostrare l'uso di un protocollo
 692 alternativo.
 693
 694 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
 695 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
 696 \func{socket} deve essere nullo. È altresì possibile usare i socket raw
 697 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
 698 per \param{protocol} è \constd{ATPROTO\_DDP}.
 699
 700 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
 701 \struct{sockaddr\_atalk}, la cui definizione è riportata in
 702 fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
 703 il file \headfiled{netatalk/at.h}.
 704
 705 \begin{figure}[!htb]
 706   \footnotesize \centering
 707   \begin{minipage}[c]{0.80\textwidth}
 708     \includestruct{listati/sockaddr_atalk.h}
 709   \end{minipage}
 710   \caption{La struttura \structd{sockaddr\_atalk} degli indirizzi dei socket
 711     AppleTalk, e la struttura \structd{at\_addr} degli indirizzi AppleTalk.}
 712   \label{fig:sock_sa_atalk_struct}
 713 \end{figure}
 714
 715 Il campo \var{sat\_family} deve essere sempre \constd{AF\_APPLETALK}, mentre
 716 il campo \var{sat\_port} specifica la porta che identifica i vari
 717 servizi. Valori inferiori a 129 sono usati per le \textsl{porte riservate}, e
 718 possono essere usati solo da processi con i privilegi di amministratore o con
 719 la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
 720
 721 L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
 722 essere in \textit{network order} (vedi sez.~\ref{sec:endianness}); esso è
 723 composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
 724 valore \constd{AT\_ANYNET}, che indica una rete generica e vale anche per
 725 indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
 726 può prendere il valore generico \constd{AT\_ANYNODE} che indica anche il nodo
 727 corrente, ed il valore \constd{ATADDR\_BCAST} che indica tutti i nodi della
 728 rete.
 729
 730
 731 \subsection{La struttura degli indirizzi dei \textit{packet socket}}
 732 \label{sec:sock_sa_packet}
 733
 734 I \textit{packet socket}, identificati dal dominio \const{AF\_PACKET}, sono
 735 un'interfaccia specifica di Linux per inviare e ricevere pacchetti
 736 direttamente su un'interfaccia di rete, senza passare per le funzioni di
 737 gestione dei protocolli di livello superiore. In questo modo è possibile
 738 implementare dei protocolli in \textit{user space}, agendo direttamente sul
 739 livello fisico. In genere comunque si preferisce usare la libreria
 740 \file{pcap},\footnote{la libreria è mantenuta insieme al comando
 741   \cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
 742   progetto \url{http://www.tcpdump.org/}.}  che assicura la portabilità su
 743 altre piattaforme, anche se con funzionalità ridotte.
 744
 745 Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
 746 Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
 747 collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
 748 del dispositivo e viceversa.  In questo modo, in fase di trasmissione, il
 749 contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
 750 fornito dall'utente. In fase di ricezione invece tutto il contenuto del
 751 pacchetto viene passato inalterato sul socket, anche se il kernel analizza
 752 comunque il pacchetto, riempiendo gli opportuni campi della struttura
 753 \struct{sockaddr\_ll} ad esso associata.
 754
 755 Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
 756 livello di rete.
 757
 758 In questo caso in fase di ricezione l'intestazione del protocollo di
 759 collegamento viene rimossa prima di passare il resto del pacchetto all'utente,
 760 mentre in fase di trasmissione viene creata una opportuna intestazione per il
 761 protocollo a livello di collegamento utilizzato, usando le informazioni
 762 necessarie che devono essere specificate sempre con una struttura
 763 \struct{sockaddr\_ll}.
 764
 765 Nella creazione di un \textit{packet socket} il valore dell'argomento
 766 \param{protocol} di \func{socket} serve a specificare, in \textit{network
 767   order}, il numero identificativo del protocollo di collegamento si vuole
 768 utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
 769 quelli disponibili in Linux sono accessibili attraverso opportune costanti
 770 simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
 771 speciale \constd{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
 772 pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
 773 di questi socket è una operazione privilegiata e può essere effettuati solo da
 774 un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o
 775 con la \textit{capability} \const{CAP\_NET\_RAW}.
 776
 777 Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
 778 specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
 779 provengono; se si vuole limitare il passaggio ad una interfaccia specifica
 780 occorre usare la funzione \func{bind} (vedi sez.~\ref{sec:TCP_func_bind}) per
 781 agganciare il socket a quest'ultima.
 782
 783 \begin{figure}[!htb]
 784   \footnotesize \centering
 785   \begin{minipage}[c]{\textwidth}
 786     \includestruct{listati/sockaddr_ll.h}
 787   \end{minipage}
 788   \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
 789     \textit{packet socket}.}
 790   \label{fig:sock_sa_packet_struct}
 791 \end{figure}
 792
 793 Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
 794 \struct{sockaddr\_ll}, e la sua definizione è riportata in
 795 fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
 796 leggermente diverso rispetto a quanto visto finora per gli altri tipi di
 797 socket.  Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
 798 scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
 799 specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
 800 tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
 801 al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
 802 entrambi i tipi di socket), per la ricezione dei dati relativi a ciascun
 803 pacchetto.
 804
 805 Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
 806 \constd{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
 807 e deve essere indicato in \textit{network order}, facendo uso delle costanti
 808 simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
 809 l'indice dell'interfaccia (l'\textit{inxterface index} (vedi
 810 sez.~\ref{sec:sock_ioctl_netdevice}) che in caso di presenza di più
 811 interfacce dello stesso tipo (se ad esempio si hanno più schede Ethernet),
 812 permette di selezionare quella con cui si vuole operare (un valore nullo
 813 indica qualunque interfaccia).  Questi sono i due soli campi che devono essere
 814 specificati quando si vuole selezionare una interfaccia specifica, usando
 815 questa struttura con la funzione \func{bind}.
 816
 817 I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
 818 l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
 819 relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
 820 collegamento che si usa, ad esempio, nel caso di Ethernet, questi saranno il
 821 MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
 822 ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
 823 pacchetti, in questo caso tutti gli altri campi devono essere nulli.
 824
 825 Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
 826 \file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
 827 pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
 828 senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
 829 seguenti valori: \constd{PACKET\_HOST} per un pacchetto indirizzato alla
 830 macchina ricevente, \constd{PACKET\_BROADCAST} per un pacchetto di
 831 \textit{broadcast}, \constd{PACKET\_MULTICAST} per un pacchetto inviato ad un
 832 indirizzo fisico di \textit{multicast}, \constd{PACKET\_OTHERHOST} per un
 833 pacchetto inviato ad un'altra stazione (e ricevuto su un'interfaccia in modo
 834 promiscuo), \constd{PACKET\_OUTGOING} per un pacchetto originato dalla propria
 835 macchina che torna indietro sul socket.
 836
 837 Si tenga presente infine che in fase di ricezione, anche se si richiede il
 838 troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
 839 \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
 840 lunghezza effettiva del pacchetto così come arrivato sulla linea.
 841
 842 %% \subsection{La struttura degli indirizzi DECnet}
 843 %% \label{sec:sock_sa_decnet}
 844
 845 %% I socket di tipo \const{AF\_DECnet} usano il protocollo DECnet, usato dai VAX
 846 %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
 847 %% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
 848 %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
 849 %% solo come esempio
 850
 851
 852 % TODO aggiungere AF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25 ?
 853
 854 % TODO: trattare i socket RDS, vedi documentazione del kernel, file
 855 % Documentation/networking/rds.txt
 856
 857
 858
 859 \section{Le funzioni di conversione degli indirizzi}
 860 \label{sec:sock_addr_func}
 861
 862 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
 863 indirizzi, limitandoci però agli indirizzi Internet.  Come accennato gli
 864 indirizzi e i numeri di porta usati nella rete devono essere forniti nel
 865 cosiddetto \textit{network order}, che corrisponde al formato \textit{big
 866   endian} (vedi sez.~\ref{sec:endianness}), anche quando la proprio macchina
 867 non usa questo formato, cosa che può comportare la necessità di eseguire delle
 868 conversioni.
 869
 870
 871 \subsection{Le funzioni per il riordinamento}
 872 \label{sec:sock_func_ord}
 873
 874 Come già visto in sez.~\ref{sec:endianness} il problema connesso
 875 all'\textit{endianness} è che quando si passano dei dati da un tipo di
 876 architettura all'altra i dati vengono interpretati in maniera diversa, e ad
 877 esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è
 878 suddiviso scambiati di posto.
 879
 880 Per questo motivo si usano delle funzioni di conversione che servono a tener
 881 conto automaticamente della possibile differenza fra l'ordinamento usato sul
 882 computer e quello che viene usato nelle trasmissione sulla rete; queste
 883 funzioni sono \funcd{htonl}, \funcd{htons}, \funcd{ntohl} e \funcd{ntohs} ed i
 884 rispettivi prototipi sono:
 885
 886 \begin{funcproto}{
 887 \fhead{arpa/inet.h}
 888 \fdecl{unsigned long int htonl(unsigned long int hostlong)}
 889 \fdesc{Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
 890   quello della rete.}
 891 \fdecl{unsigned short int htons(unsigned short int hostshort)}
 892 \fdesc{Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
 893   quello della rete.}
 894 \fdecl{unsigned long int ntohl(unsigned long int netlong)}
 895 \fdesc{Converte l'intero a 32 bit \param{netlong} dal formato della rete a
 896   quello della macchina.}
 897 \fdecl{unsigned sort int ntohs(unsigned short int netshort)}
 898 \fdesc{Converte l'intero a 16 bit \param{netshort} dal formato della rete a
 899   quello della macchina.}
 900 }
 901
 902 {Tutte le funzioni restituiscono il valore convertito, e non prevedono
 903   errori.}
 904 \end{funcproto}
 905
 906 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
 907 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
 908 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
 909 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
 910 indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
 911 prototipi).
 912
 913 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
 914 macchina che si sta usando abbia una architettura \textit{big endian} queste
 915 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
 916 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
 917 assicurare la portabilità del codice su tutte le architetture.
 918
 919
 920 \subsection{Le funzioni di conversione per gli indirizzi IPv4}
 921 \label{sec:sock_func_ipv4}
 922
 923 Un secondo insieme di funzioni di manipolazione è quello che serve per passare
 924 dalla rappresentazione simbolica degli indirizzi IP al formato binario
 925 previsto dalla struttura degli indirizzi di
 926 fig.~\ref{fig:sock_sa_ipv4_struct}, e viceversa. La notazione più comune è la
 927 cosiddetta notazione \itindex{dotted-decimal} \textit{dotted-decimal}, che
 928 prevede che gli indirizzi IPv4 siano indicati con l'espressione del valore
 929 numerico decimale di ciascuno dei 4 byte che li costituiscono separati da un
 930 punto (ad esempio \texttt{192.168.0.1}).
 931
 932 In realtà le funzioni che illustreremo supportano una notazione che più
 933 propriamente dovrebbe esser chiamata \textit{numbers-and-dot} in quanto il
 934 valore può essere indicato con numeri espressi sia in decimale, che in ottale
 935 (se indicati apponendo uno zero) che in esadecimale (se indicati apponendo
 936 \texttt{0x}). Inoltre per la parte meno significativa dell'espressione, quella
 937 che riguarda l'indirizzo locale, si può usare, eliminando altrettanti punti,
 938 valori a 16 o a 24 bit, e togliendo tutti i punti, si può usare anche
 939 direttamente un valore numerico a 32 bit.\footnote{la funzionalità si trova
 940   anche in gran parte dei programmi che usano indirizzi di rete, e deriva
 941   direttamente da queste funzioni.}
 942
 943 Tradizionalmente la conversione di un indirizzo \textit{dotted-decimal} al
 944 valore numerico veniva eseguita dalla funzione \funcd{inet\_addr} (prevista
 945 fin dalle origini in BSD e inclusa in POSIX.1-2001) il cui prototipo è:
 946
 947 \begin{funcproto}{
 948 \fhead{arpa/inet.h}
 949 \fdecl{in\_addr\_t inet\_addr(const char *strptr)}
 950 \fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in nel
 951   numero IP in network order.}
 952 }
 953
 954 {La funzione ritorna il valore dell'indirizzo in caso di successo e
 955   \const{INADDR\_NONE} per un errore e non genera codici di errore.}
 956 \end{funcproto}
 957
 958 La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
 959 \textit{network order} (del tipo \type{in\_addr\_t}) a partire dalla stringa
 960 passata nell'argomento \param{strptr}. In caso di errore (quando la stringa
 961 non esprime un indirizzo valido) restituisce invece il valore
 962 \const{INADDR\_NONE}, che tipicamente sono trentadue bit a uno.  Questo però
 963 comporta che la stringa \texttt{255.255.255.255}, che pure è un indirizzo
 964 valido, non può essere usata con questa funzione dato che genererebe comunque
 965 un errore; per questo motivo essa è generalmente deprecata in favore di
 966 \func{inet\_aton}.
 967
 968 Per effettuare la conversione inversa la funzione usata tradizionalmente è
 969 \funcd{inet\_ntoa}, anch'essa presente fin da BSD 4.3, in cui si riprende la
 970 notazione già vista in sez.~\ref{sec:sock_func_ord} che usa la lettera
 971 \texttt{n} come mnemonico per indicare la rete ed \texttt{a} (per ASCII) come
 972 mnemonico per indicare la stringa corrispodente all'indirizzo; il suo
 973 prototipo è:
 974
 975 \begin{funcproto}{
 976 \fhead{arpa/inet.h}
 977 \fdecl{char *inet\_ntoa(struct in\_addr addrptr)}
 978 \fdesc{Converte un indirizzo IP in una stringa \textit{dotted decimal}.}
 979 }
 980
 981 {La funzione l'indirizzo della stringa con il valore dell'indirizzo convertito
 982   e non prevede errori.}
 983 \end{funcproto}
 984
 985 La funzione converte il valore a 32 bit dell'indirizzo, espresso in
 986 \textit{network order}, e preso direttamente con un puntatore al relativo
 987 campo della struttura degli indirizzi, restituendo il puntatore alla stringa
 988 che contiene l'espressione in formato \textit{dotted-decimal}. Si deve tenere
 989 presente che la stringa risiede in un segmento di memoria statica, per cui
 990 viene riscritta ad ogni chiamata e la funzione non è rientrante.
 991
 992 Per rimediare ai problemi di \funcd{inet\_addr} è stata sostituita da
 993 \funcd{inet\_aton}, che però non è stata standardizzata e non è presente in
 994 POSIX.1-2001, anche se è definita sulla gran parte dei sistemi Unix; il suo
 995 prototipo è:
 996
 997 \begin{funcproto}{
 998 \fhead{arpa/inet.h}
 999 \fdecl{int inet\_aton(const char *src, struct in\_addr *dest)}
1000 \fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in un
1001   indirizzo IP.}
1002 }
1003
1004 {La funzione ritorna un valore non nullo in caso di successo e $0$ per un
1005   errore e non genera codici di errore.}
1006 \end{funcproto}
1007
1008 La funzione converte la stringa puntata da \param{src} nell'indirizzo binario
1009 che viene memorizzato nell'opportuna struttura \struct{in\_addr} (si veda
1010 fig.~\ref{fig:sock_sa_ipv4_struct}) situata all'indirizzo dato
1011 dall'argomento \param{dest} (è espressa in questa forma in modo da poterla
1012 usare direttamente con il puntatore usato per passare la struttura degli
1013 indirizzi). La funzione restituisce un valore diverso da zero se l'indirizzo è
1014 valido e la conversione ha successo e 0 in caso contrario. Se usata
1015 con \param{dest} inizializzato a \val{NULL} può essere usata per effettuare la
1016 validazione dell'indirizzo espresso da \param{src}.
1017
1018 Oltre a queste tre funzioni esistono le ulteriori \funcm{inet\_lnaof},
1019 \funcm{inet\_netof} e \funcm{inet\_makeaddr} che assumono la ormai obsoleta e
1020 deprecata suddivisione in classi degli indirizzi IP per fornire la parte di
1021 rete e quella di indirizzo locale. Ad oggi il loro uso non ha più alcun senso
1022 per ciò non le tratteremo.
1023
1024
1025 \subsection{Le funzioni di conversione per indirizzi IP generici}
1026 \label{sec:sock_conv_func_gen}
1027
1028 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
1029 motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
1030 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
1031 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
1032 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
1033 e \textit{numeric}.
1034
1035 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
1036 indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
1037 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
1038 indirizzo; il suo prototipo è:
1039
1040 \begin{funcproto}{
1041 \fhead{sys/socket.h}
1042 \fdecl{int inet\_pton(int af, const char *src, void *addr\_ptr)}
1043 \fdesc{Converte l'indirizzo espresso tramite una stringa nel valore numerico.}
1044 }
1045
1046 {La funzione ritorna $1$ in caso di successo, $0$ se \param{src} non contiene
1047   una rappresentazione valida per la famiglia di indirizzi indicati
1048   da \param{af} e $-1$ se \param{af} specifica una famiglia di indirizzi non
1049   valida, e solo in quest'ultimo caso  \var{errno} assumerà il valore
1050   \errcode{EAFNOSUPPORT}.
1051 }
1052 \end{funcproto}
1053
1054 La funzione converte la stringa indicata tramite \param{src} nel valore
1055 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
1056 memorizzato all'indirizzo puntato da \param{addr\_ptr}. La funzione supporta
1057 per IPv4 la sola notazione \textit{dotted-decimal}, e non quella più completa
1058 \textit{number-and-dot} che abbiamo visto per \func{inet\_aton}. Per IPv6 la
1059 notazione prevede la suddivisione dei 128 bit dell'indirizzo in 16 parti di 16
1060 bit espresse con valori esadecimali separati dal carattere ``\texttt{:}'' ed
1061 una serie di valori nulli possono essere sostituiti (una sola volta, sempre a
1062 partire dalla sinistra) con la notazione ``\texttt{::}'', un esempio di
1063 indirizzo in questa forma potrebbe essere \texttt{2001:db8::8:ba98:2078:e3e3},
1064 per una descrizione più completa si veda sez.~\ref{sec:IP_ipv6_notation}.
1065
1066 La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
1067 indirizzo in una stringa; il suo prototipo è:
1068
1069 \begin{funcproto}{
1070 \fhead{sys/socket.h}
1071 \fdecl{char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
1072 \fdesc{Converte l'indirizzo dalla relativa struttura in una stringa simbolica.}
1073 }
1074
1075 {La funzione ritorna un puntatore non nullo alla stringa convertita in caso di
1076   successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
1077   dei valori:
1078   \begin{errlist}
1079     \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
1080       dell'indirizzo eccedono la lunghezza specificata da \param{len}.
1081     \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
1082       una valida.
1083   \end{errlist}
1084 }
1085 \end{funcproto}
1086
1087
1088 La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
1089 in una stringa che viene copiata nel buffer puntato dall'indirizzo
1090 \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
1091 essere almeno \constd{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
1092 \constd{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
1093 comunque essere specificata con il parametro \param{len}.
1094
1095 Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
1096 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
1097 per IPv6), che devono essere precedentemente allocate e passate attraverso il
1098 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
1099 può essere nullo e deve essere allocato precedentemente.
1100
1101
1102
1103
1104
1105 % LocalWords:  socket sez cap BSD SVr XTI Transport Interface TCP stream UDP PF
1106 % LocalWords:  datagram broadcast descriptor sys int domain type protocol errno
1107 % LocalWords:  EPROTONOSUPPORT ENFILE kernel EMFILE EACCES EINVAL ENOBUFS raw
1108 % LocalWords:  ENOMEM table family AF address name glibc UNSPEC LOCAL Local IPv
1109 % LocalWords:  communication INET protocols ip AX Amateur IPX Novell APPLETALK
1110 % LocalWords:  Appletalk ddp NETROM NetROM Multiprotocol ATMPVC Access to ATM
1111 % LocalWords:  PVCs ITU ipv PLP DECnet Reserved for project NETBEUI LLC KEY key
1112 % LocalWords:  SECURITY Security callback NETLINK interface device netlink Low
1113 % LocalWords:  PACKET level packet ASH Ash ECONET Acorn Econet ATMSVC SVCs SNA
1114 % LocalWords:  IRDA PPPOX PPPoX WANPIPE Wanpipe BLUETOOTH Bluetooth POSIX bits
1115 % LocalWords:  dall'header tab SOCK capabilities capability styles DGRAM read
1116 % LocalWords:  SEQPACKET RDM sockaddr reference void fig Header uint socklen at
1117 % LocalWords:  addr netinet port len Stevens unsigned short casting nell'header
1118 % LocalWords:  BIND SERVICE bind union order big endian flowinfo dell'header ll
1119 % LocalWords:  multicast multicasting local socketpair sun path filesystem AARP
1120 % LocalWords:  pathname AppleTalk netatalk personal Apple ATPROTO atalk sat if
1121 % LocalWords:  ANYNET node ANYNODE ATADDR BCAST pcap IEEE linux ether ETH ALL
1122 % LocalWords:  sll ifindex ethernet halen MAC hatype ARP arp pkttype HOST recv
1123 % LocalWords:  OTHERHOST OUTGOING recvfrom recvmsg endianness little endtest Mac
1124 % LocalWords:  Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
1125 % LocalWords:  htons ntohl ntohs long hostlong hostshort netlong
1126 % LocalWords:  sort netshort host inet aton ntoa dotted decimal const char src
1127 % LocalWords:  strptr struct dest addrptr INADDR NULL pton ntop presentation af
1128 % LocalWords:  numeric EAFNOSUPPORT size ENOSPC ENOAFSUPPORT ADDRSTRLEN ROUTE
1129 % LocalWords:  of tcpdump page
1130
1131
1132 %%% Local Variables:
1133 %%% mode: latex
1134 %%% TeX-master: "gapil"
1135 %%% End: