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