socket.tex

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