socket.tex

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