socket.tex

   1 %% socket.tex
   2 %%
   3 %% Copyright (C) 2000-2002 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 "Prefazione",
   7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
   8 %% license is included in the section entitled "GNU Free Documentation
   9 %% License".
  10 %%
  11 \chapter{Introduzione ai socket}
  12 \label{cha:socket_intro}
  13
  14 In questo capitolo inizieremo a spiegare le caratteristiche salienti della
  15 principale interfaccia per la programmazione di rete, quella dei
  16 \textit{socket}, che, pur essendo nata in ambiente Unix è usata ormai da tutti
  17 i sistemi operativi.
  18
  19 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
  20 come creare un socket e come collegarlo allo specifico protocollo di rete che
  21 si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
  22 teorica concluderemo il capitolo con un primo esempio di applicazione.
  23
  24 \section{Una panoramica}
  25 \label{sec:sock_overview}
  26
  27 Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di
  28 quali sono i concetti fondamentali da tenere presente quando si ha a che fare
  29 con essi.
  30 \index{socket|(}
  31
  32
  33 \subsection{I \textit{socket}}
  34 \label{sec:sock_socket_def}
  35
  36 I \textit{socket}\footnote{una traduzione letterale potrebbe essere
  37   \textsl{presa}, ma essendo universalmente noti come socket utilizzeremo
  38   sempre la parola inglese.} sono uno dei principali meccanismi di
  39 comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati in
  40 \secref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione fra
  41 processi. Un socket costituisce in sostanza un canale di comunicazione fra due
  42 processi su cui si possono leggere e scrivere dati analogo a quello di una
  43 pipe (vedi \secref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
  44 meccanismi esaminati nel capitolo \capref{cha:IPC}, i socket non sono limitati
  45 alla comunicazione fra processi che girano sulla stessa macchina, ma possono
  46 realizzare la comunicazione anche attraverso la rete.
  47
  48 Quella dei socket costituisce infatti la principale interfaccia usata nella
  49 programmazione di rete.  La loro origine risale al 1983, quando furono
  50 introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
  51 piccole modifiche, negli anni successivi. Benché siano state sviluppate
  52 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
  53   Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
  54 di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
  55
  56 La flessibilità e la genericità dell'interfaccia inoltre consente di
  57 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
  58 solo con la suite dei protocolli TCP/IP, anche se questa sarà comunque quella
  59 di cui tratteremo in maniera più estesa.
  60
  61
  62 \subsection{Concetti base}
  63 \label{sec:sock_gen}
  64
  65 Per capire il funzionamento dei socket occorre avere presente il funzionamento
  66 dei protocolli di rete (vedi \capref{cha:network}), ma l'interfaccia è del
  67 tutto generale e benché le problematiche (e quindi le modalità di risolvere i
  68 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
  69 usato, le funzioni da usare restano le stesse.
  70
  71 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
  72 inutile, in quanto il comportamento di quest'ultima e le problematiche da
  73 affrontare cambiano radicalmente a seconda dello \textsl{stile} di
  74 comunicazione usato.  La scelta di questo stile va infatti ad incidere sulla
  75 semantica che verrà utilizzata a livello utente per gestire la comunicazione
  76 (su come inviare e ricevere i dati) e sul comportamento effettivo delle
  77 funzioni utilizzate.
  78
  79 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
  80 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
  81 comunicazione considerano i dati come una sequenza continua di byte, altri
  82 invece li raggruppano in blocchi (i pacchetti).
  83
  84 Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
  85 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
  86 inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
  87
  88 Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
  89 avviene, in certi casi essa può essere condotta con una connessione diretta
  90 con un solo corrispondente, come per una telefonata; altri casi possono
  91 prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
  92 ogni pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
  93 radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove
  94 chiunque si collega possa riceverli.
  95
  96 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
  97 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
  98 gestire la perdita o il rimescolamento dei dati.
  99
 100
 101 \section{La creazione di un \textit{socket}}
 102 \label{sec:sock_creation}
 103
 104 Come accennato l'interfaccia dei socket è estremamente flessibile e permette
 105 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
 106 in questa sezione vedremo come è possibile creare un socket e come specificare
 107 il tipo di comunicazione che esso deve utilizzare.
 108
 109 \subsection{La funzione \func{socket}}
 110 \label{sec:sock_socket}
 111
 112 La creazione di un socket avviene attraverso l'uso della funzione
 113 \funcd{socket}; questa restituisce un \textit{file descriptor}\footnote{del
 114   tutto analogo a quelli che si ottengono per i file di dati e le pipe,
 115   descritti in \secref{sec:file_fd}.} che serve come riferimento al socket; il
 116 suo prototipo è:
 117 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
 118
 119   Apre un socket.
 120
 121   \bodydesc{La funzione restituisce un intero positivo in caso di successo, e
 122     -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
 123   i valori:
 124   \begin{errlist}
 125   \item[\errcode{EPROTONOSUPPORT}] Il tipo di socket o il protocollo scelto non
 126     sono supportati nel dominio.
 127   \item[\errcode{ENFILE}] Il kernel non ha memoria sufficiente a creare una
 128     nuova struttura per il socket.
 129   \item[\errcode{EMFILE}] Si è ecceduta la tabella dei file.
 130   \item[\errcode{EACCES}] Non si hanno privilegi per creare un socket nel
 131     dominio o con il protocollo specificato.
 132   \item[\errcode{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
 133   \item[\errcode{ENOBUFS}] Non c'è sufficiente memoria per creare il socket
 134     (può essere anche \errval{ENOMEM}).
 135   \end{errlist}}
 136 \end{prototype}
 137
 138 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
 139 (definisce cioè la famiglia di protocolli, come vedremo in
 140 \secref{sec:sock_domain}), \param{type} specifica il tipo di socket (definisce
 141 cioè lo stile di comunicazione, come vedremo in \secref{sec:sock_type}) e
 142 \param{protocol} il protocollo; in genere quest'ultimo è indicato
 143 implicitamente dal tipo di socket, per cui viene messo a zero (con l'eccezione
 144 dei \textit{raw socket}).
 145
 146 Si noti che la creazione del socket si limita ad allocare le opportune
 147 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
 148 non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
 149 attraverso i quali si vuole effettuare la comunicazione.
 150
 151 \subsection{Il dominio, o \textit{protocol family}}
 152 \label{sec:sock_domain}
 153
 154 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
 155 tipi di socket, che vengono classificati raggruppandoli in quelli che si
 156 chiamano \textsl{domini}.  La scelta di un dominio equivale in sostanza alla
 157 scelta di una famiglia di protocolli, e viene effettuata attraverso
 158 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
 159 suo nome simbolico che convenzionalmente inizia con una costante che inizia
 160 per \texttt{PF\_}, iniziali di \textit{protocol family}, un altro nome con cui
 161 si indicano i domini.
 162
 163 A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
 164 associato ad una costante, che inizia invece per \texttt{AF\_} (da
 165 \textit{address family}) che identifica il formato degli indirizzi usati in
 166 quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
 167 anche come \textit{name space},\footnote{nome che invece il manuale delle
 168   \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
 169 identificano il formato degli indirizzi usati in quel dominio per identificare
 170 i capi della comunicazione.
 171
 172 \begin{table}[htb]
 173   \footnotesize
 174   \centering
 175   \begin{tabular}[c]{|l|l|l|l|}
 176        \hline
 177        \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
 178        \hline
 179        \hline
 180        \const{PF\_UNSPEC}   & 0& Non specificato               &            \\
 181        \const{PF\_LOCAL}    & 1& Local communication           & unix(7)    \\
 182        \const{PF\_UNIX}, \const{PF\_FILE}&1&                   &            \\
 183        \const{PF\_INET}     & 2& IPv4 Internet protocols       & ip(7)      \\
 184        \const{PF\_AX25}     & 3& Amateur radio AX.25 protocol  &            \\
 185        \const{PF\_IPX}      & 4& IPX - Novell protocols        &            \\
 186        \const{PF\_APPLETALK}& 5& Appletalk                     & ddp(7)     \\
 187        \const{PF\_NETROM}   & 6& Amateur radio NetROM          &            \\
 188        \const{PF\_BRIDGE}   & 7& Multiprotocol bridge          &            \\
 189        \const{PF\_ATMPVC}   & 8& Access to raw ATM PVCs        &            \\
 190        \const{PF\_X25}      & 9& ITU-T X.25 / ISO-8208 protocol& x25(7)     \\
 191        \const{PF\_INET6}    &10& IPv6 Internet protocols       & ipv6(7)    \\
 192        \const{PF\_ROSE}     &11& Amateur Radio X.25 PLP        &            \\
 193        \const{PF\_DECnet}   &12& Reserved for DECnet project   &            \\
 194        \const{PF\_NETBEUI}  &13& Reserved for 802.2LLC project &            \\
 195        \const{PF\_SECURITY} &14& Security callback pseudo AF   &            \\
 196        \const{PF\_KEY}      &15& PF\_KEY key management API    &            \\
 197        \const{PF\_NETLINK}  &16& Kernel user interface device  & netlink(7) \\
 198        \const{PF\_PACKET}   &17& Low level packet interface    & packet(7)  \\
 199        \const{PF\_ASH}      &18& Ash                           &    \\
 200        \const{PF\_ECONET}   &19& Acorn Econet                  &    \\
 201        \const{PF\_ATMSVC}   &20& ATM SVCs                      &    \\
 202        \const{PF\_SNA}      &22& Linux SNA Project             &    \\
 203        \const{PF\_IRDA}     &23& IRDA sockets                  &    \\
 204        \const{PF\_PPPOX}    &24& PPPoX sockets                 &    \\
 205        \const{PF\_WANPIPE}  &25& Wanpipe API sockets           &    \\
 206        \const{PF\_BLUETOOTH}&31& Bluetooth sockets             &    \\
 207        \hline
 208   \end{tabular}
 209   \caption{Famiglie di protocolli definiti in Linux.}
 210   \label{tab:net_pf_names}
 211 \end{table}
 212
 213 L'idea alla base della distinzione fra questi due insiemi di costanti era che
 214 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
 215 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
 216 il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
 217 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
 218 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
 219 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
 220 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
 221   il contenuto di \file{bits/socket.h} le costanti sono esattamente le stesse
 222   e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
 223   lo stesso nome.}
 224
 225 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
 226 indirizzi, sono definiti dall'header \textit{socket.h}. Un elenco delle
 227 famiglie di protocolli disponibili in Linux è riportato in
 228 \tabref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
 229   definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
 230   compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
 231   viene definita anche una costante \const{PF\_MAX} che indica il valore
 232   massimo associabile ad un dominio (nel caso 32).}
 233
 234 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
 235 dall'utente generico, ad esempio in generale tutti i socket di tipo
 236 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
 237 di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
 238 capability \texttt{CAP\_NET\_RAW}.
 239
 240
 241 \subsection{Il tipo, o stile}
 242 \label{sec:sock_type}
 243
 244 La scelta di un dominio non comporta però la scelta dello stile di
 245 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 246 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
 247 socket permette di scegliere lo stile di comunicazione indicando il tipo di
 248 socket con l'argomento \param{type} di \func{socket}. Linux mette a
 249 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
 250 della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
 251 seguenti costanti:
 252
 253 \begin{basedescript}{\desclabelwidth{2.8cm}\desclabelstyle{\nextlinelabel}}
 254 \item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati
 255   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 256   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
 257   byte (da cui il nome \textit{stream}).
 258 \item[\const{SOCK\_DGRAM}] Viene usato per mandare pacchetti di lunghezza
 259   massima fissata (\textit{datagram}) indirizzati singolarmente, senza
 260   connessione e in maniera non affidabile. È l'opposto del precedente.
 261 \item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
 262   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
 263   altro socket. I dati possono solo essere trasmessi e letti per pacchetti (di
 264   dimensione massima fissata).
 265 \item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
 266   rete e alle varie interfacce. I normali programmi di comunicazione non
 267   devono usarlo.
 268 \item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di pacchetti
 269   affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
 270 \item[\const{SOCK\_PACKET}] Obsoleto, non deve essere usato.
 271 \end{basedescript}
 272
 273 Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
 274 e un tipo di socket sono valide, in quanto non è detto che in una famiglia
 275 esista un protocollo per ciascuno dei diversi stili di comunicazione appena
 276 elencati.
 277
 278 \begin{table}[htb]
 279   \footnotesize
 280   \centering
 281   \begin{tabular}{l|c|c|c|c|c|}
 282    \multicolumn{1}{c}{} &\multicolumn{1}{c}{\const{SOCK\_STREAM}}&
 283      \multicolumn{1}{c}{\const{SOCK\_DGRAM}} &
 284      \multicolumn{1}{c}{\const{SOCK\_RAW}} &
 285      \multicolumn{1}{c}{\const{SOCK\_PACKET}}&
 286      \multicolumn{1}{c}{\const{SOCK\_SEQPACKET}} \\
 287      \cline{2-6}
 288     \const{PF\_UNIX}      &  si & si  &      &     &     \\
 289      \cline{2-6}
 290     \const{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
 291      \cline{2-6}
 292     \const{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
 293      \cline{2-6}
 294     \const{PF\_IPX}       &     &     &      &     &     \\
 295      \cline{2-6}
 296     \const{PF\_NETLINK}   &     &  si &  si  &     &     \\
 297      \cline{2-6}
 298     \const{PF\_X25}       &     &     &      &     &  si \\
 299      \cline{2-6}
 300     \const{PF\_AX25}      &     &     &      &     &     \\
 301      \cline{2-6}
 302     \const{PF\_ATMPVC}    &     &     &      &     &     \\
 303      \cline{2-6}
 304     \const{PF\_APPLETALK} &     & si  &  si  &     &     \\
 305      \cline{2-6}
 306     \const{PF\_PACKET}    &     & si  & si   &     &     \\
 307      \cline{2-6}
 308   \end{tabular}
 309   \caption{Combinazioni valide di dominio e tipo di protocollo per la
 310     funzione \func{socket}.}
 311   \label{tab:sock_sock_valid_combinations}
 312 \end{table}
 313
 314 In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
 315 valide possibili per le principali famiglie di protocolli. Per ogni
 316 combinazione valida si è indicato il tipo di protocollo, o la parola
 317 \textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
 318 sono lasciate vuote le caselle per le combinazioni non supportate.
 319
 320
 321 \section{Le strutture degli indirizzi dei socket}
 322 \label{sec:sock_sockaddr}
 323
 324 Come si è visto nella creazione di un socket non si specifica nulla oltre al
 325 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
 326 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
 327 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
 328 comunicazione.
 329
 330 Gli indirizzi infatti vengono specificati attraverso apposite strutture che
 331 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
 332 la comunicazione viene effettivamente realizzata.  Ogni famiglia di protocolli
 333 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
 334 sua peculiare struttura degli indirizzi; i nomi di tutte queste strutture
 335 iniziano per \var{sockaddr\_}, quelli propri di ciascuna famiglia vengono
 336 identificati dal suffisso finale, aggiunto al nome precedente.
 337
 338
 339 \subsection{La struttura generica}
 340 \label{sec:sock_sa_gen}
 341
 342 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
 343 attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
 344 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 345 nelle varie famiglie di protocolli; questo pone il problema di come passare
 346 questi puntatori, il C moderno risolve questo problema coi i puntatori
 347 generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
 348 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
 349 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
 350 è riportata in \figref{fig:sock_sa_gen_struct}.
 351
 352 \begin{figure}[!htb]
 353   \footnotesize \centering
 354   \begin{minipage}[c]{15cm}
 355     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 356 struct sockaddr {
 357     sa_family_t  sa_family;     /* address family: AF_xxx */
 358     char         sa_data[14];   /* address (protocol-specific) */
 359 };
 360     \end{lstlisting}
 361   \end{minipage}
 362   \caption{La struttura generica degli indirizzi dei socket
 363     \structd{sockaddr}.}
 364   \label{fig:sock_sa_gen_struct}
 365 \end{figure}
 366
 367 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
 368 prototipo un puntatore a questa struttura; per questo motivo quando si
 369 invocano dette funzioni passando l'indirizzo di un protocollo specifico
 370 occorrerà eseguire una coversione (il \textit{casting}) del relativo
 371 puntatore.
 372
 373 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 374 POSIX.1g e li abbiamo riassunti in \tabref{tab:sock_data_types} con i
 375 rispettivi file di include in cui sono definiti; la struttura è invece
 376 definita nell'include file \file{sys/socket.h}.
 377
 378 \begin{table}[!htb]
 379   \centering
 380   \footnotesize
 381   \begin{tabular}{|l|l|l|}
 382     \hline
 383     \multicolumn{1}{|c|}{\textbf{Tipo}}&
 384     \multicolumn{1}{|c|}{\textbf{Descrizione}}&
 385     \multicolumn{1}{|c|}{\textbf{Header}} \\
 386     \hline
 387     \hline
 388     \type{int8\_t}   & intero a 8 bit con segno   & \file{sys/types.h}\\
 389     \type{uint8\_t}  & intero a 8 bit senza segno & \file{sys/types.h}\\
 390     \type{int16\_t}  & intero a 16 bit con segno  & \file{sys/types.h}\\
 391     \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
 392     \type{int32\_t}  & intero a 32 bit con segno  & \file{sys/types.h}\\
 393     \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
 394     \hline
 395     \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
 396     \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
 397     un socket& \file{sys/socket.h}\\
 398     \hline
 399     \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
 400     \file{netinet/in.h}\\
 401     \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
 402     \file{netinet/in.h}\\
 403     \hline
 404   \end{tabular}
 405   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
 406     stabilito dallo standard POSIX.1g.}
 407   \label{tab:sock_data_types}
 408 \end{table}
 409
 410 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
 411 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
 412 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
 413 non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
 414 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
 415
 416 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
 417 di fare da riferimento per il casting, per il kernel le cose sono un po'
 418 diverse, in quanto esso usa il puntatore per recuperare il campo
 419 \var{sa\_family} con cui determinare il tipo di indirizzo; per questo
 420 motivo, anche se l'uso di un puntatore \ctyp{void *} sarebbe più immediato
 421 per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto
 422 l'uso di questa struttura.
 423
 424
 425 \subsection{La struttura degli indirizzi IPv4}
 426 \label{sec:sock_sa_ipv4}
 427
 428 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
 429 attraverso internet; la struttura per gli indirizzi per un socket internet (se
 430 si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
 431 \file{netinet/in.h} ed ha la forma mostrata in
 432 \figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 433
 434 \begin{figure}[!htb]
 435   \footnotesize\centering
 436   \begin{minipage}[c]{15cm}
 437     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 438 struct sockaddr_in {
 439     sa_family_t     sin_family; /* address family: AF_INET */
 440     u_int16_t       sin_port;   /* port in network byte order */
 441     struct in_addr  sin_addr;   /* internet address */
 442 };
 443 /* Internet address. */
 444 struct in_addr {
 445     u_int32_t       s_addr;     /* address in network byte order */
 446 };
 447     \end{lstlisting}
 448   \end{minipage}
 449   \caption{La struttura degli indirizzi dei socket internet (IPv4)
 450     \structd{sockaddr\_in}.}
 451   \label{fig:sock_sa_ipv4_struct}
 452 \end{figure}
 453
 454 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
 455 internet di un'interfaccia più un numero di porta. Il protocollo IP non
 456 prevede numeri di porta, che sono utilizzati solo dai protocolli di livello
 457 superiore come TCP e UDP. Questa struttura però viene usata anche per i socket
 458 RAW che accedono direttamente al livello di IP, nel qual caso il numero della
 459 porta viene impostato al numero di protocollo.
 460
 461 Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
 462 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
 463 specifica il \textsl{numero di porta} (affronteremo in dettaglio in le
 464 \textsl{porte} in \secref{sec:TCPel_port_num}). I numeri di porta sotto il
 465 1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi standard
 466 e soltanto processi con i privilegi di amministratore (con user-ID effettivo
 467 uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
 468 usare la funzione \func{bind} (che vedremo in \secref{sec:TCPel_func_bind}) su
 469 queste porte.
 470
 471 Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
 472 come struttura (un resto di una implementazione precedente in cui questa era
 473 una \direct{union} usata per accedere alle diverse classi di indirizzi) che
 474 direttamente come intero. In \file{netinet/in.h} vengono definiti anche alcune
 475 costanti per alcuni indirizzi speciali, che vedremo in
 476 \tabref{tab:TCPel_ipv4_addr}.
 477
 478 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
 479 essere specificati in quello che viene chiamato \textit{network order}, cioè
 480 con i bit ordinati in formato \textit{big endian}, questo comporta la
 481 necessità di usare apposite funzioni di conversione per mantenere la
 482 portabilità del codice (vedi \secref{sec:sock_addr_func} per i dettagli del
 483 problema e le relative soluzioni).
 484
 485
 486 \subsection{La struttura degli indirizzi IPv6}
 487 \label{sec:sock_sa_ipv6}
 488
 489 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
 490 sostanzialmente identici ai precedenti; la parte in cui si trovano
 491 praticamente tutte le differenze fra i due socket è quella della struttura
 492 degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
 493 in \figref{fig:sock_sa_ipv6_struct}.
 494
 495 \begin{figure}[!htb]
 496   \footnotesize \centering
 497   \begin{minipage}[c]{15cm}
 498     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 499 struct sockaddr_in6 {
 500     u_int16_t       sin6_family;   /* AF_INET6 */
 501     u_int16_t       sin6_port;     /* port number */
 502     u_int32_t       sin6_flowinfo; /* IPv6 flow information */
 503     struct in6_addr sin6_addr;     /* IPv6 address */
 504     u_int32_t       sin6_scope_id; /* Scope id (new in 2.4) */
 505 };
 506
 507 struct in6_addr {
 508     unsigned char   s6_addr[16];   /* IPv6 address */
 509 };
 510     \end{lstlisting}
 511   \end{minipage}
 512   \caption{La struttura degli indirizzi dei socket IPv6
 513     \structd{sockaddr\_in6}.}
 514   \label{fig:sock_sa_ipv6_struct}
 515 \end{figure}
 516
 517 Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
 518 il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
 519 il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
 520 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
 521 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
 522 specifici dell'header dei pacchetti IPv6 (vedi \secref{sec:IP_ipv6head}) ed il
 523 loro uso è sperimentale.
 524
 525 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, infine
 526 il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il kernel
 527 2.4, per gestire alcune operazioni riguardanti il multicasting.
 528
 529 Si noti che questa struttura è più grande della \struct{sockaddr} generica
 530 vista in \figref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non
 531 avere fatto assunzioni riguardo alla possibilità di contenere i dati nelle
 532 dimensioni di quest'ultima.
 533
 534
 535 \subsection{La struttura degli indirizzi locali}
 536 \label{sec:sock_sa_local}
 537
 538 I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
 539 comunicazione fra processi che stanno sulla stessa macchina (per vengono
 540 chiamati \textit{local domain} o anche \textit{Unix domain}); essi rispetto ai
 541 precedenti possono essere anche creati in maniera anonima attraverso la
 542 funzione \func{socketpair} (vedi \secref{sec:ipc_socketpair}). Quando però si
 543 vuole fare riferimento esplicito ad uno di questi socket si deve usare la
 544 seguente struttura di indirizzi definita nel file di header \file{sys/un.h}.
 545
 546 \begin{figure}[!htb]
 547   \footnotesize \centering
 548   \begin{minipage}[c]{15cm}
 549     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 550 #define UNIX_PATH_MAX    108
 551 struct sockaddr_un {
 552     sa_family_t  sun_family;              /* AF_UNIX */
 553     char         sun_path[UNIX_PATH_MAX]; /* pathname */
 554 };
 555     \end{lstlisting}
 556   \end{minipage}
 557   \caption{La struttura degli indirizzi dei socket locali
 558     \structd{sockaddr\_un}.}
 559   \label{fig:sock_sa_local_struct}
 560 \end{figure}
 561
 562 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
 563 il campo \var{sun\_path} deve specificare un indirizzo; questo ha due forme:
 564 un file (di tipo socket) nel filesystem o una stringa univoca (mantenuta in
 565 uno spazio di nomi astratto). Nel primo caso l'indirizzo viene specificato
 566 come una stringa (terminata da uno zero) corrispondente al pathname del file;
 567 nel secondo invece \var{sun\_path} inizia con uno zero vengono usati i
 568 restanti byte come stringa (senza terminazione).
 569
 570
 571 \subsection{La struttura degli indirizzi AppleTalk}
 572 \label{sec:sock_sa_appletalk}
 573
 574 I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
 575 \file{netatalk} per implementare la comunicazione secondo il protocollo
 576 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
 577 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
 578 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
 579 opportuno usare le funzioni di libreria, si tratta qui questo argomento
 580 principalmente per mostrare l'uso di un protocollo alternativo.
 581
 582 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
 583 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
 584 \func{socket} deve essere nullo. È altresì possibile usare i socket raw
 585 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
 586 per \param{protocol} è \func{ATPROTO\_DDP}.
 587
 588 \begin{figure}[!htb]
 589   \footnotesize \centering
 590   \begin{minipage}[c]{15cm}
 591     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 592 struct sockaddr_atalk {
 593     sa_family_t     sat_family; /* address family */
 594     u_char          sat_port;   /* port */
 595     struct at_addr  sat_addr;   /* net/node */
 596 };
 597
 598 struct at_addr {
 599     unsigned short  s_net;
 600     unsigned char   s_node;
 601 };
 602     \end{lstlisting}
 603   \end{minipage}
 604   \caption{La struttura degli indirizzi dei socket AppleTalk
 605     \structd{sockaddr\_atalk}.}
 606   \label{fig:sock_sa_atalk_struct}
 607 \end{figure}
 608
 609 Il campo \var{sut\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
 610 campo \var{sun\_port} specifica la porta che identifica i vari servizi. Valori
 611 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 612 usati solo da processi con i privilegi di amministratore o con la capability
 613 \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
 614 struttura \var{sun\_addr}, e deve essere in \textit{network order}; esso è
 615 composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
 616 valore \const{AT\_ANYNET}, che indica una rete genrica e vale anche per
 617 indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
 618 può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
 619 corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
 620 rete.
 621
 622
 623
 624
 625
 626 \subsection{La struttura degli indirizzi DECnet}
 627 \label{sec:sock_sa_decnet}
 628
 629 I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
 630 Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
 631 fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è di
 632 compatibilità con macchine che stanno comunque scomparendo. Lo si riporta solo
 633 come esempio
 634
 635
 636
 637 % \subsection{Il passaggio delle strutture}
 638 % \label{sec:sock_addr_pass}
 639
 640 % Come detto nelle funzioni della API dei socket le strutture degli indirizzi
 641 % vengono sempre passate per riferimento usando un puntatore; anche la lunghezza
 642 % della struttura è passata come argomento, ma in questo caso la modalità del
 643 % passaggio dipende dalla direzione del medesimo, dal processo al kernel o
 644 % viceversa.
 645
 646 % In particolare le tre funzioni \texttt{bind}, \texttt{connect} e
 647 % \texttt{sendto} passano la struttura al kernel, in questo caso è passata
 648 % \textsl{per valore} anche la dimensione della medesima
 649
 650
 651 % Le funzioni \texttt{accept}, \texttt{recvfrom}, \texttt{getsockname} e
 652 % \texttt{getpeername} invece ricevono i valori del kernel
 653
 654
 655
 656 \section{Le funzioni di conversione degli indirizzi}
 657 \label{sec:sock_addr_func}
 658
 659 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
 660 indirizzi, limitandoci però agli indirizzi internet.
 661
 662 Come accennato gli indirizzi e i numeri di porta usati nella rete devono
 663 essere forniti in formato opportuno (il \textit{network order}). Per capire
 664 cosa significa tutto ciò occorre introdurre un concetto generale che tornerà
 665 utile anche in seguito.
 666
 667
 668 \subsection{La \textit{endianess}\index{endianess}}
 669 \label{sec:sock_endianess}
 670
 671 La rappresentazione di un numero binario in un computer può essere fatta in
 672 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
 673   endian} a seconda di come i singoli bit vengono aggregati per formare le
 674 variabili intere (ed in genere in diretta corrispondenza a come sono poi in
 675 realtà cablati sui bus interni del computer).
 676
 677 Per capire meglio il problema si consideri un intero a 16 bit scritto in una
 678 locazione di memoria posta ad un certo indirizzo. I singoli bit possono essere
 679 disposti un memoria in due modi: a partire dal più significativo o a partire
 680 dal meno significativo. Così nel primo caso si troverà il byte che contiene i
 681 bit più significativi all'indirizzo menzionato e il byte con i bit meno
 682 significativi nell'indirizzo successivo; questo ordinamento è detto
 683 \textit{little endian} dato che il dato finale è la parte ``piccola'' del
 684 numero. Il caso opposto, in cui si parte dal bit meno significativo è detto
 685 per lo stesso motivo \textit{big endian}.
 686
 687 La \textit{endianess}\index{endianess} di un computer dipende essenzialmente
 688 dalla architettura hardware usata; Intel e Digital usano il \textit{little
 689   endian}, Motorola, IBM, Sun (sostanzialmente tutti gli altri) usano il
 690 \textit{big endian}. Il formato della rete è anch'esso \textit{big endian},
 691 altri esempi di uso di questi formati sono quello del bus PCI, che è
 692 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
 693
 694 Esistono poi anche dei processori che possono scegliere il tipo di formato
 695 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
 696 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
 697 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
 698 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
 699 questi cambiamenti.
 700
 701 \subsection{Le funzioni per il riordinamento}
 702 \label{sec:sock_func_ord}
 703
 704 Il problema connesso all'endianess\index{endianess} è che quando si passano
 705 dei dati da un tipo di architettura all'altra i dati vengono interpretati in
 706 maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
 707 con i due byte in cui è suddiviso scambiati di posto, e ne sarà quindi
 708 invertito l'ordine di lettura per cui, per riavere il valore originale,
 709 dovranno essere rovesciati.
 710
 711 Per questo motivo si usano delle funzioni di conversione che servono a tener
 712 conto automaticamente della possibile differenza fra l'ordinamento usato sul
 713 computer e quello che viene usato nelle trasmissione sulla rete; queste
 714 funzioni sono \funcd{htonl}, \funcd{htons}, \funcd{ntonl} e \funcd{ntons} ed i
 715 rispettivi prototipi sono:
 716 \begin{functions}
 717   \headdecl{netinet/in.h}
 718   \funcdecl{unsigned long int htonl(unsigned long int hostlong)}
 719   Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
 720   quello della rete.
 721
 722   \funcdecl{unsigned short int htons(unsigned short int hostshort)}
 723   Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
 724   quello della rete.
 725
 726   \funcdecl{unsigned long int ntonl(unsigned long int netlong)}
 727   Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
 728   della macchina.
 729
 730   \funcdecl{unsigned sort int ntons(unsigned short int netshort)}
 731   Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
 732   della macchina.
 733
 734   \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non hanno
 735     errori.}
 736 \end{functions}
 737
 738 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
 739 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
 740 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
 741 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
 742 indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
 743 prototipi).
 744
 745 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
 746 macchina che si sta usando abbia una architettura \textit{big endian} queste
 747 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
 748 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
 749 assicurare la portabilità del codice su tutte le architetture.
 750
 751
 752 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
 753   \func{inet\_ntoa}}
 754 \label{sec:sock_func_ipv4}
 755
 756 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
 757 binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
 758 dei numeri IP che si usa normalmente.
 759
 760 Le prime tre funzioni di manipolazione riguardano la conversione degli
 761 indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
 762 cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
 763 \texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
 764   order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
 765 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
 766 \funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
 767 \begin{functions}
 768   \headdecl{arpa/inet.h}
 769
 770   \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
 771   dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
 772
 773   \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
 774   la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
 775
 776   \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
 777   Converte un indirizzo IP in una stringa \textit{dotted decimal}.
 778
 779   \bodydesc{Tutte queste le funzioni non generano codice di errore.}
 780 \end{functions}
 781
 782 La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
 783 network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
 784 nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
 785 un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
 786 tipicamente sono trentadue bit a uno.  Questo però comporta che la stringa
 787 \texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
 788 con questa funzione; per questo motivo essa è generalmente deprecata in favore
 789 di \func{inet\_aton}.
 790
 791 La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
 792 nell'indirizzo binario che viene memorizzato nell'opportuna struttura
 793 \struct{in\_addr} (si veda \secref{fig:sock_sa_ipv4_struct}) situata
 794 all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
 795 modo da poterla usare direttamente con il puntatore usato per passare la
 796 struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
 797 in caso di fallimento.  Se usata con \param{dest} inizializzato a \val{NULL}
 798 effettua la validazione dell'indirizzo.
 799
 800 L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
 801 dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
 802 alla stringa che contiene l'espressione in formato dotted decimal. Si deve
 803 tenere presente che la stringa risiede in memoria statica, per cui questa
 804 funzione non è rientrante.
 805
 806
 807 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
 808 \label{sec:sock_conv_func_gen}
 809
 810 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
 811 motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
 812 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
 813 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
 814 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
 815 e \textit{numeric}.
 816
 817 % \begin{figure}[htb]
 818 %   \centering
 819
 820 %   \caption{Schema della rappresentazioni utilizzate dalle funzioni di
 821 %     conversione \texttt{inet\_pton} e \texttt{inet\_ntop} }
 822 %   \label{fig:sock_inet_conv_func}
 823
 824 % \end{figure}
 825
 826 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
 827 indirizzo e può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La prima
 828 funzione è \funcd{inet\_pton}, che serve a convertire una stringa in un
 829 indirizzo, il suo prototipo è:
 830 \begin{prototype}{sys/socket.h}
 831 {int inet\_pton(int af, const char *src, void *addr\_ptr)}
 832
 833   Converte l'indirizzo espresso tramite una stringa nel valore numerico.
 834
 835   \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
 836     una famiglia di indirizzi non valida, con \var{errno} che assume il valore
 837     \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
 838     indirizzo valido, ed un valore positivo in caso di successo.}
 839 \end{prototype}
 840
 841 La funzione converte la stringa indicata tramite \param{src} nel valore
 842 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
 843 memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione restituisce
 844 un valore positivo in caso di successo, e zero se la stringa non rappresenta
 845 un indirizzo valido, e negativo se \param{af} specifica una famiglia di
 846 indirizzi non valida.
 847
 848 La seconda funzione è \funcd{inet\_ntop} che converte un indirizzo in una
 849 stringa; il suo prototipo è:
 850 \begin{prototype}{sys/socket.h}
 851   {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
 852   Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
 853
 854   \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
 855     convertita in caso di successo e \val{NULL} in caso di fallimento, nel
 856     qual caso \var{errno} assume i valori:
 857     \begin{errlist}
 858     \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
 859       dell'indirizzo eccedono la lunghezza specificata da \param{len}.
 860     \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
 861       una valida.
 862   \end{errlist}}
 863 \end{prototype}
 864
 865 La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
 866 in una stringa che viene copiata nel buffer puntato dall'indirizzo
 867 \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
 868 essere almeno \const{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
 869 \const{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
 870 comunque venire specificata attraverso il parametro \param{len}.
 871
 872 Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
 873 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
 874 per IPv6), che devono essere precedentemente allocate e passate attraverso il
 875 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
 876 può essere nullo e deve essere allocato precedentemente.
 877
 878 Il formato usato per gli indirizzi in formato di presentazione è la notazione
 879 \textit{dotted decimal} per IPv4 e quello descritto in
 880 \secref{sec:IP_ipv6_notation} per IPv6.
 881
 882 \index{socket|)}
 883
 884
 885 \section{Un esempio di applicazione}
 886 \label{sec:sock_appplication}
 887
 888 Per evitare di rendere questa introduzione ai socket puramente teorica
 889 iniziamo con il mostrare un esempio di un client TCP elementare.  Prima di
 890 passare agli esempi del client e del server, ritorniamo con maggiori dettagli
 891 su una caratteristica delle funzioni di I/O che nel caso dei socket è
 892 particolarmente rilevante, e che ci tornerà utile anche in seguito.
 893
 894
 895 \subsection{Il comportamento delle funzioni di I/O}
 896 \label{sec:sock_io_behav}
 897
 898 Una cosa di cui non sempre si è consapevoli quando si ha a che fare con i
 899 socket è che le funzioni di input/output non sempre hanno lo stesso
 900 comportamento che avrebbero con i normali files (in particolare questo accade
 901 per i socket di tipo stream).
 902
 903 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
 904 possano restituire in input o scrivere in output un numero di byte minore di
 905 quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
 906 comportamento normale per l'I/O su file; con i normali file di dati il
 907 problema si avverte solo quando si incontra la fine del file, ma in generale
 908 non è così.
 909
 910 In questo caso tutto quello che il programma chiamante deve fare è di ripetere
 911 la lettura (o scrittura) per la quantità di byte rimanenti (e le funzioni si
 912 possono bloccare se i dati non sono disponibili): è lo stesso comportamento
 913 che si può avere scrivendo più di \const{PIPE\_BUF} byte in una pipe (si
 914 riveda quanto detto in \secref{sec:ipc_pipes}).
 915
 916 \begin{figure}[htb]
 917   \centering
 918   \footnotesize
 919   \begin{lstlisting}{}
 920 #include <unistd.h>
 921
 922 ssize_t FullRead(int fd, void *buf, size_t count)
 923 {
 924     size_t nleft;
 925     ssize_t nread;
 926
 927     nleft = count;
 928     while (nleft > 0) {             /* repeat until no left */
 929         if ( (nread = read(fd, buf, nleft)) < 0) {
 930             if (errno == EINTR) {   /* if interrupted by system call */
 931                 continue;           /* repeat the loop */
 932             } else {
 933                 return(nread);      /* otherwise exit */
 934             }
 935         } else if (nread == 0) {    /* EOF */
 936             break;                  /* break loop here */
 937         }
 938         nleft -= nread;             /* set left to read */
 939         buf +=nread;                /* set pointer */
 940     }
 941     return (count - nleft);
 942 }
 943   \end{lstlisting}
 944   \caption{Funzione \func{FullRead}, legge \var{count} byte da un socket }
 945   \label{fig:sock_FullRead_code}
 946 \end{figure}
 947
 948 Per questo motivo, seguendo l'esempio di W. R. Stevens in \cite{UNP1}, si sono
 949 definite due funzioni \func{FullRead} e \func{FullWrite} che eseguono la
 950 lettura da un socket tenendo conto di questa caratteristica, ed in grado di
 951 ritornare dopo avere letto o scritto esattamente il numero di byte
 952 specificato; il sorgente è riportato in \figref{fig:sock_FullRead_code} e
 953 \figref{fig:sock_FullWrite_code} ed è disponibile fra i sorgenti allegati alla
 954 guida nei files \file{FullRead.c} e \file{FullWrite.c}.
 955
 956 \begin{figure}[htb]
 957   \centering
 958   \footnotesize
 959   \begin{lstlisting}{}
 960 #include <unistd.h>
 961
 962 ssize_t FullWrite(int fd, const void *buf, size_t count)
 963 {
 964     size_t nleft;
 965     ssize_t nwritten;
 966
 967     nleft = count;
 968     while (nleft > 0) {             /* repeat until no left */
 969         if ( (nwritten = write(fd, buf, nleft)) < 0) {
 970             if (errno == EINTR) {   /* if interrupted by system call */
 971                 continue;           /* repeat the loop */
 972             } else {
 973                 return(nwritten);   /* otherwise exit with error */
 974             }
 975         }
 976         nleft -= nwritten;          /* set left to write */
 977         buf +=nwritten;             /* set pointer */
 978     }
 979     return (count);
 980 }
 981   \end{lstlisting}
 982   \caption{Funzione \func{FullWrite}, scrive \var{count} byte su un socket.}
 983   \label{fig:sock_FullWrite_code}
 984 \end{figure}
 985
 986 Come si può notare le funzioni ripetono la lettura/scrittura in un ciclo fino
 987 all'esaurimento del numero di byte richiesti, in caso di errore viene
 988 controllato se questo è \errcode{EINTR} (cioè un'interruzione della system call
 989 dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
 990 l'errore viene ritornato interrompendo il ciclo.
 991
 992 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
 993 arrivati alla fine del file (per i socket questo significa in genere che
 994 l'altro capo è stato chiuso, e non è quindi più possibile leggere niente) e
 995 pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
 996
 997
 998
 999 \subsection{Un primo esempio di client}
1000 \label{sec:net_cli_sample}
1001
1002 Lo scopo di questo esempio è fornire un primo approccio alla programmazione di
1003 rete e vedere come si usano le funzioni descritte in precedenza, alcune delle
1004 funzioni usate nell'esempio saranno trattate in dettaglio nel capitolo
1005 successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
1006 definizioni precise e dettagli di funzionamento che saranno trattati
1007 estensivamente più avanti.
1008
1009 In \figref{fig:net_cli_code} è riportata la sezione principale del codice del
1010 nostro client elementare per il servizio \textit{daytime}, un servizio
1011 standard che restituisce l'ora locale della macchina a cui si effettua la
1012 richiesta.
1013
1014 \begin{figure}[!htb]
1015   \footnotesize
1016   \begin{lstlisting}{}
1017 #include <sys/types.h>   /* predefined types */
1018 #include <unistd.h>      /* include unix standard library */
1019 #include <arpa/inet.h>   /* IP addresses conversion utilities */
1020 #include <sys/socket.h>  /* socket library */
1021 #include <stdio.h>       /* include standard I/O library */
1022
1023 int main(int argc, char *argv[])
1024 {
1025     int sock_fd;
1026     int i, nread;
1027     struct sockaddr_in serv_add;
1028     char buffer[MAXLINE];
1029      ...
1030     /* create socket */
1031     if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
1032         perror("Socket creation error");
1033         return -1;
1034     }
1035     /* initialize address */
1036     memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
1037     serv_add.sin_family = AF_INET;                   /* address type is INET */
1038     serv_add.sin_port = htons(13);                   /* daytime post is 13 */
1039     /* build address using inet_pton */
1040     if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
1041         perror("Address creation error");
1042         return -1;
1043     }
1044     /* extablish connection */
1045     if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
1046         perror("Connection error");
1047         return -1;
1048     }
1049     /* read daytime from server */
1050     while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
1051         buffer[nread]=0;
1052         if (fputs(buffer, stdout) == EOF) {          /* write daytime */
1053             perror("fputs error");
1054             return -1;
1055         }
1056     }
1057     /* error on read */
1058     if (nread < 0) {
1059         perror("Read error");
1060         return -1;
1061     }
1062     /* normal exit */
1063     return 0;
1064 }
1065   \end{lstlisting}
1066   \caption{Esempio di codice di un client elementare per il servizio daytime.}
1067   \label{fig:net_cli_code}
1068 \end{figure}
1069
1070 Il sorgente completo del programma (\file{ElemDaytimeTCPClient.c}, che
1071 comprende il trattamento delle opzioni e una funzione per stampare un
1072 messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
1073 può essere compilato su una qualunque macchina Linux.
1074
1075 Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
1076 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
1077 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
1078 comando (effettuata con le apposite routine illustrate in
1079 \capref{sec:proc_opt_handling}).
1080
1081 Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
1082 (\const{AF\_INET}), di tipo TCP \const{SOCK\_STREAM}. La funzione
1083 \func{socket} ritorna il descrittore che viene usato per identificare il
1084 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
1085 stampa un errore con la relativa routine e si esce.
1086
1087 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
1088 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
1089 il numero della porta del servizio. Il primo passo è inizializzare tutto a
1090 zero, per poi inserire il tipo di protocollo e la porta (usando per
1091 quest'ultima la funzione \func{htons} per convertire il formato dell'intero
1092 usato dal computer a quello usato nella rete), infine si utilizza la funzione
1093 \func{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di
1094 comando.
1095
1096 Usando la funzione \func{connect} sul socket creato in precedenza
1097 (\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
1098 server specificato dall'indirizzo immesso nella struttura passata come secondo
1099 argomento, il terzo argomento è la dimensione di detta struttura. Dato che
1100 esistono diversi tipi di socket, si è dovuto effettuare un cast della
1101 struttura inizializzata in precedenza, che è specifica per i socket IPv4.  Un
1102 valore di ritorno negativo implica il fallimento della connessione.
1103
1104 Completata con successo la connessione il passo successivo (\texttt{\small
1105   34--40}) è leggere la data dal socket; il server invierà sempre una stringa
1106 di 26 caratteri della forma \verb|Wed Apr 4 00:53:00 2001\r\n|, che viene
1107 letta dalla funzione \func{read} e scritta su \file{stdout}.
1108
1109 Dato il funzionamento di TCP la risposta potrà tornare in un unico pacchetto
1110 di 26 byte (come avverrà senz'altro nel caso in questione) ma potrebbe anche
1111 arrivare in 26 pacchetti di un byte.  Per questo nel caso generale non si può
1112 mai assumere che tutti i dati arrivino con una singola lettura, pertanto
1113 quest'ultima deve essere effettuata in un ciclo in cui si continui a leggere
1114 fintanto che la funzione \func{read} non ritorni uno zero (che significa che
1115 l'altro capo ha chiuso la connessione) o un numero minore di zero (che
1116 significa un errore nella connessione).
1117
1118 Si noti come in questo caso la fine dei dati sia specificata dal server che
1119 chiude la connessione; questa è una delle tecniche possibili (è quella usata
1120 pure dal protocollo HTTP), ma ce ne possono essere altre, ad esempio FTP marca
1121 la conclusione di un blocco di dati con la sequenza ASCII \verb|\r\n|
1122 (carriage return e line feed), mentre il DNS mette la lunghezza in testa ad
1123 ogni blocco che trasmette. Il punto essenziale è che TCP non provvede nessuna
1124 indicazione che permetta di marcare dei blocchi di dati, per cui se questo è
1125 necessario deve provvedere il programma stesso.
1126
1127 \subsection{Un primo esempio di server}
1128 \label{sec:net_serv_sample}
1129
1130 Dopo aver illustrato il client daremo anche un esempio di un server
1131 elementare, in grado di rispondere al precedente client. Il listato è
1132 nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo
1133 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
1134 directory \file{sources}.
1135
1136 \begin{figure}[!htbp]
1137   \footnotesize
1138   \begin{lstlisting}{}
1139 #include <sys/types.h>   /* predefined types */
1140 #include <unistd.h>      /* include unix standard library */
1141 #include <arpa/inet.h>   /* IP addresses conversion utilities */
1142 #include <sys/socket.h>  /* socket library */
1143 #include <stdio.h>       /* include standard I/O library */
1144 #include <time.h>
1145 #define MAXLINE 80
1146 #define BACKLOG 10
1147 int main(int argc, char *argv[])
1148 {
1149 /*
1150  * Variables definition
1151  */
1152     int list_fd, conn_fd;
1153     int i;
1154     struct sockaddr_in serv_add;
1155     char buffer[MAXLINE];
1156     time_t timeval;
1157     ...
1158     /* create socket */
1159     if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
1160         perror("Socket creation error");
1161         exit(-1);
1162     }
1163     /* initialize address */
1164     memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
1165     serv_add.sin_family = AF_INET;                  /* address type is INET */
1166     serv_add.sin_port = htons(13);                  /* daytime port is 13 */
1167     serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
1168     /* bind socket */
1169     if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
1170         perror("bind error");
1171         exit(-1);
1172     }
1173     /* listen on socket */
1174     if (listen(list_fd, BACKLOG) < 0 ) {
1175         perror("listen error");
1176         exit(-1);
1177     }
1178     /* write daytime to client */
1179     while (1) {
1180         if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
1181             perror("accept error");
1182             exit(-1);
1183         }
1184         timeval = time(NULL);
1185         snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
1186         if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
1187             perror("write error");
1188             exit(-1);
1189         }
1190         close(conn_fd);
1191     }
1192     /* normal exit */
1193     exit(0);
1194 }
1195   \end{lstlisting}
1196   \caption{Esempio di codice di un semplice server per il servizio daytime.}
1197   \label{fig:net_serv_code}
1198 \end{figure}
1199
1200 Come per il client si includono gli header necessari a cui è aggiunto quello
1201 per trattare i tempi, e si definiscono alcune costanti e le variabili
1202 necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
1203 sono omesse le parti relative al trattamento delle opzioni da riga di comando.
1204
1205 La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
1206 come pure l'inizializzazione della struttura \struct{sockaddr\_in}, anche in
1207 questo caso si usa la porta standard del servizio daytime, ma come indirizzo
1208 IP si il valore predefinito \const{INET\_ANY} che corrisponde ad un indirizzo
1209 generico (\texttt{\small 27--31}).
1210
1211 Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
1212 \func{bind} che permette di associare la precedente struttura al socket, in
1213 modo che quest'ultimo possa essere usato per accettare connessioni su una
1214 qualunque delle interfacce di rete locali.
1215
1216 Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
1217 socket, questo viene effettuato con la funzione \func{listen} che dice al
1218 kernel di accettare connessioni per il socket specificato, la funzione indica
1219 inoltre, con il secondo parametro, il numero massimo di connessioni che il
1220 kernel accetterà di mettere in coda per il suddetto socket.
1221
1222 Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
1223 viene chiamato anche \textit{listening descriptor}) a questo punto il processo
1224 è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
1225 funzione \func{accept}, fin quando non arriva e viene accettata una
1226 connessione da un client.
1227
1228 Quando questo avviene \func{accept} ritorna un secondo descrittore di socket,
1229 che viene chiamato \textit{connected descriptor} che è quello che viene usato
1230 dalla successiva chiamata alla \func{write} per scrivere la risposta al
1231 client, una volta che si è opportunamente (\texttt{\small 48--49}) costruita
1232 la stringa con la data da trasmettere. Completata la trasmissione il nuovo
1233 socket viene chiuso (\texttt{\small 54}).  Il tutto è inserito in un ciclo
1234 infinito (\texttt{\small 42--55}) in modo da poter ripetere l'invio della data
1235 ad una successiva connessione.
1236
1237 È importante notare che questo server è estremamente elementare, infatti a
1238 parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
1239 un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
1240 scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
1241 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
1242 attiva e il terminale da cui lo si è lanciato è stato sconnesso),
1243 occorrerebbero delle opportune modifiche.
1244
1245
1246
1247 %%% Local Variables:
1248 %%% mode: latex
1249 %%% TeX-master: "gapil"
1250 %%% End: