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