socket.tex

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