Passaggio a UTF-8 dei sorgenti
[gapil.git] / socket.tex
index 619c1dd15ad0f29ef7684673bbcd254af4068ca0..efca2ca21b1d4b5d58f2924b9998e9b65a06d6ab 100644 (file)
@@ -1,15 +1,26 @@
+%% socket.tex
+%%
+%% Copyright (C) 2000-2011 Simone Piccardi.  Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
+
 \chapter{Introduzione ai socket}
 \label{cha:socket_intro}
 
 \chapter{Introduzione ai socket}
 \label{cha:socket_intro}
 
-In questo capitolo inizieremo a spiegare le caratteristiche principali della
+In questo capitolo inizieremo a spiegare le caratteristiche salienti della
 principale interfaccia per la programmazione di rete, quella dei
 principale interfaccia per la programmazione di rete, quella dei
-\textit{socket}, che pur essendo nata in unix è usata ormai da tutti i sistemi
-operativi.
+\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
+tutti i sistemi operativi.
 
 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
 come creare un socket e come collegarlo allo specifico protocollo di rete che
 
 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
 come creare un socket e come collegarlo allo specifico protocollo di rete che
-utilizzerà per la comunicazione. Per evitare un'introduzione puramente teorica
-concluderemo il capitolo con un primo esempio di applicazione.
+si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
+teorica concluderemo il capitolo con un primo esempio di applicazione.
 
 \section{Una panoramica}
 \label{sec:sock_overview}
 
 \section{Una panoramica}
 \label{sec:sock_overview}
@@ -18,317 +29,372 @@ Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di
 quali sono i concetti fondamentali da tenere presente quando si ha a che fare
 con essi.
 
 quali sono i concetti fondamentali da tenere presente quando si ha a che fare
 con essi.
 
+\index{socket!definizione|(}
+
 \subsection{I \textit{socket}}
 \label{sec:sock_socket_def}
 
 \subsection{I \textit{socket}}
 \label{sec:sock_socket_def}
 
-Il \textit{socket}\footnote{una traduzione letterale potrebbe essere
-  \textsl{presa}, ma essendo universalmente noti come socket utilizzeremo
-  sempre la parola inglese.} è uno dei principali meccanismi di comunicazione
-fra programmi utilizzato in ambito Unix. Il socket costituisce in sostanza un
-canale di comunicazione fra due processi su cui si possono leggere e scrivere
-dati analogo a quello di una pipe ma a differenza di questa e degli altri
-meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati
-alla comunicazione fra processi che girano sulla stessa macchina ma possono
-effettuare la comunicazione anche attraverso la rete.
-
-Quella dei socket costituisce infatti la principale API (\textit{Application
-  Program Interface}) usata nella programmazione di rete.  La loro origine
-risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
-sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
-siano state sviluppate interfacce alternative, originate dai sistemi SVr4,
-come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
-diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
-flessibilità).
-
-La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
-utilizzare i socket con i più disparati meccanismi di comunicazione, e non
-solo con la suite dei protocolli TCP/IP, che sarà comunque quella di cui
-tratteremo in maniera più estesa.
+I \textit{socket}\footnote{una traduzione letterale potrebbe essere
+  \textsl{presa}, ma essendo universalmente noti come \textit{socket}
+  utilizzeremo sempre la parola inglese.} sono uno dei principali meccanismi
+di comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati
+in sez.~\ref{sec:ipc_socketpair}, fra i vari meccanismi di intercomunicazione
+fra processi. Un socket costituisce in sostanza un canale di comunicazione fra
+due processi su cui si possono leggere e scrivere dati analogo a quello di una
+pipe (vedi sez.~\ref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
+meccanismi esaminati nel capitolo cap.~\ref{cha:IPC}, i socket non sono
+limitati alla comunicazione fra processi che girano sulla stessa macchina, ma
+possono realizzare la comunicazione anche attraverso la rete.
+
+Quella dei socket costituisce infatti la principale interfaccia usata nella
+programmazione di rete.  La loro origine risale al 1983, quando furono
+introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
+piccole modifiche, negli anni successivi. Benché siano state sviluppate
+interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
+  Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
+di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
+
+La flessibilità e la genericità dell'interfaccia inoltre consente di
+utilizzare i socket con i più disparati meccanismi di comunicazione, e non
+solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
+di cui tratteremo in maniera più estesa.
 
 
 \subsection{Concetti base}
 \label{sec:sock_gen}
 
 Per capire il funzionamento dei socket occorre avere presente il funzionamento
 
 
 \subsection{Concetti base}
 \label{sec:sock_gen}
 
 Per capire il funzionamento dei socket occorre avere presente il funzionamento
-dei protocolli di rete (vedi \capref{cha:network}), ma l'interfaccia è del
-tutto generale e benché le problematiche (e quindi le modalità di risolvere i
+dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
+tutto generale e benché le problematiche (e quindi le modalità di risolvere i
 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
 usato, le funzioni da usare restano le stesse.
 
 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
 usato, le funzioni da usare restano le stesse.
 
-Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
+Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
 inutile, in quanto il comportamento di quest'ultima e le problematiche da
 inutile, in quanto il comportamento di quest'ultima e le problematiche da
-affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione
-usato.  La scelta di questo stile va infatti ad incidere sulla semantica che
-verrà utilizzata a livello utente per gestire la comunicazione (su come
-inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
-utilizzate.
+affrontare cambiano radicalmente a seconda dello \textsl{stile} di
+comunicazione usato.  La scelta di questo stile va infatti ad incidere sulla
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
+(su come inviare e ricevere i dati) e sul comportamento effettivo delle
+funzioni utilizzate.
 
 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
 
 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
-comunicazione considerano i dati come una sequenza continua di byte, altri
-invece li raggruppano in blocchi (i pacchetti).
+comunicazione considerano i dati come una sequenza continua di byte, in quello
+che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
+altri invece li raggruppano in \textsl{pacchetti} (in inglese
+\textit{datagram}) che vengono inviati in blocchi separati.
 
 
-Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
+Un altro esempio di stile concerne la possibilità che la comunicazione possa o
 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
-inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
+inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
 
 
-Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
-avviene, in certi casi essa può essere condotta con una connessione diretta
-con un solo partner come per una telefonata; altri casi possono prevedere una
-comunicazione come per lettera, in cui si scrive l'indirizzo su ogni
-pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
-radio, in cui i pacchetti vengono emessi su appositi ``canali'' dove chiunque
-si collega possa riceverli.
+Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
+avviene, in certi casi essa può essere condotta con una connessione diretta
+con un solo corrispondente, come per una telefonata; altri casi possono
+prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
+ogni pacchetto, altri ancora una comunicazione \itindex{broadcast}
+\textit{broadcast} come per la radio, in cui i pacchetti vengono emessi su
+appositi ``\textsl{canali}'' dove chiunque si collega possa riceverli.
 
 
-É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
-la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
-gestire la perdita o il rimescolamento dei dati.
+É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
+la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
+gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
+dovranno essere opportunamente trattati, ecc.
 
 
 
 
-\section{La creazione di un \textit{socket}}
+\section{La creazione di un socket}
 \label{sec:sock_creation}
 
 \label{sec:sock_creation}
 
-Come accennato l'interfaccia dei socket è estremamente flessibile e permette
+Come accennato l'interfaccia dei socket è estremamente flessibile e permette
 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
-in questa sezione vedremo come è possibile creare un socket e come specificare
+in questa sezione vedremo come è possibile creare un socket e come specificare
 il tipo di comunicazione che esso deve utilizzare.
 
 \subsection{La funzione \func{socket}}
 \label{sec:sock_socket}
 
 La creazione di un socket avviene attraverso l'uso della funzione
 il tipo di comunicazione che esso deve utilizzare.
 
 \subsection{La funzione \func{socket}}
 \label{sec:sock_socket}
 
 La creazione di un socket avviene attraverso l'uso della funzione
-\func{socket} questa restituisce un \textit{socket descriptor} (un valore
-intero non negativo) che come gli analoghi file descriptor di file e alle
-pipe serve come riferimento al socket; in sostanza è l'indice nella tabella
-dei file che contiene i puntatori alle opportune strutture usate dal kernel ed
-allocate per ogni processo, (la stessa usata per i files e le pipes [NdA
-verificare!]).
-
-La funzione prende tre parametri, il dominio del socket (che definisce la
-famiglia di protocolli, vedi \secref{sec:sock_domain}), il tipo di socket (che
-definisce lo stile di comunicazione vedi \secref{sec:sock_type}) e il
-protocollo; in genere quest'ultimo è indicato implicitamente dal tipo di
-socket, per cui viene messo a zero (con l'eccezione dei \textit{raw socket}).
-
+\funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
+  tutto analogo a quelli che si ottengono per i file di dati e le pipe,
+  descritti in sez.~\ref{sec:file_fd}.} che serve come riferimento al socket;
+il suo prototipo è:
 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
 
   Apre un socket.
   
 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
 
   Apre un socket.
   
-  \bodydesc{La funzione restituisce un intero positivo se riesce, e -1 se
-    fallisce, in quest'ultimo caso la variabile \var{errno} è settata con i
-    seguenti codici di errore:
-
+  \bodydesc{La funzione restituisce un intero positivo in caso di successo, e
+    -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
+  i valori:
   \begin{errlist}
   \begin{errlist}
-  \item[\macro{EPROTONOSUPPORT}] Il tipo di socket o il protocollo scelto non
-    sono supportati nel dominio.
-  \item[\macro{ENFILE}] Il kernel non ha memoria sufficiente a creare una
+  \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
+    non sono supportati nel dominio.
+  \item[\errcode{ENFILE}] il kernel non ha memoria sufficiente a creare una
     nuova struttura per il socket.
     nuova struttura per il socket.
-  \item[\macro{EMFILE}] Si è ecceduta la tabella dei file.
-  \item[\macro{EACCES}] Non si hanno privilegi per creare un socket nel
+  \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
+  \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
     dominio o con il protocollo specificato.
     dominio o con il protocollo specificato.
-  \item[\macro{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
-  \item[\macro{ENOBUFS}] Non c'è sufficiente memoria per creare il socket (può
-    essere anche \macro{ENOMEM}).
-  \end{errlist}}
+  \item[\errcode{EINVAL}] protocollo sconosciuto o dominio non disponibile.
+  \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
+    (può essere anche \errval{ENOMEM}).
+  \end{errlist}
+  inoltre, a seconda del protocollo usato, potranno essere generati altri
+  errori, che sono riportati nelle relative pagine di manuale.}
 \end{prototype}
 
 \end{prototype}
 
-Si noti che la creazione del socket non comporta nulla riguardo
-all'indicazione degli indirizzi remoti o locali attraverso i quali si vuole
-effettuare la comunicazione.
+La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
+(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
+protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
+come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
+\param{protocol} il protocollo; in genere quest'ultimo è indicato
+implicitamente dal tipo di socket, per cui di norma questo valore viene messo
+a zero (con l'eccezione dei \textit{raw socket}).
+
+Si noti che la creazione del socket si limita ad allocare le opportune
+strutture nel kernel (sostanzialmente una voce nella \itindex{file~table}
+\textit{file table}) e non comporta nulla riguardo all'indicazione degli
+indirizzi remoti o locali attraverso i quali si vuole effettuare la
+comunicazione.
 
 
-\subsection{Il dominio, o \textit{protocol family}}
+\subsection{Il dominio dei socket}
 \label{sec:sock_domain}
 
 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
 tipi di socket, che vengono classificati raggruppandoli in quelli che si
 chiamano \textsl{domini}.  La scelta di un dominio equivale in sostanza alla
 \label{sec:sock_domain}
 
 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
 tipi di socket, che vengono classificati raggruppandoli in quelli che si
 chiamano \textsl{domini}.  La scelta di un dominio equivale in sostanza alla
-scelta di una famiglia di protocolli. Ciascun dominio ha un suo nome simbolico
-che convenzionalmente inizia con \texttt{PF\_} da \textit{protocol family},
-altro nome con cui si indicano i domini.
-
-A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
-\texttt{AF\_} da \textit{address family}, e che identifica il formato degli
-indirizzi usati in quel dominio; le man pages di Linux si riferiscono a questi
-anche come \textit{name space}, (nome che però il manuale della glibc riserva
-ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
-
-L'idea alla base della distinzione era che una famiglia di protocolli potesse
-supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si
-sarebbe dovuto usare nella creazione dei socket e il prefisso \texttt{AF\_} in
-quello delle strutture degli indirizzi; questo è quanto specificato anche
-dallo standard POSIX.1g, ma non esistono a tuttora famiglie di protocolli che
-supportino diverse strutture di indirizzi, per cui nella pratica questi due
-nomi sono equivalenti e corrispondono agli stessi valori.
-
-I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
-indirizzi sono definiti dall'header \textit{socket.h}. In Linux le famiglie di
-protocolli disponibili sono riportate in \ntab.
+scelta di una famiglia di protocolli, e viene effettuata attraverso
+l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
+suo nome simbolico che convenzionalmente è indicato da una costante che inizia
+per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
+cui si indicano i domini.
+
+A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
+associato ad una costante, che inizia invece per \texttt{AF\_} (da
+\textit{address family}) che identifica il formato degli indirizzi usati in
+quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
+anche come \textit{name space},\footnote{nome che invece il manuale delle
+  \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
+identificano il formato degli indirizzi usati in quel dominio per identificare
+i capi della comunicazione.
 
 \begin{table}[htb]
   \footnotesize
   \centering
 
 \begin{table}[htb]
   \footnotesize
   \centering
-  \begin{tabular}[c]{|l|l|l|}
+  \begin{tabular}[c]{|l|l|l|l|}
        \hline
        \hline
-       \textbf{Nome}      & \textbf{Utilizzo}           &\textbf{Man page} \\
+       \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
        \hline
        \hline
        \hline
        \hline
-       \macro{PF\_UNIX},
-       \macro{PF\_LOCAL}  & Local communication            & unix(7)    \\
-       \macro{PF\_INET}   & IPv4 Internet protocols        & ip(7)      \\
-       \macro{PF\_INET6}  & IPv6 Internet protocols        &            \\
-       \macro{PF\_IPX}    & IPX - Novell protocols         &            \\
-       \macro{PF\_NETLINK}& Kernel user interface device   & netlink(7) \\
-       \macro{PF\_X25}    & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\
-       \macro{PF\_AX25}   & Amateur radio AX.25 protocol   &            \\
-       \macro{PF\_ATMPVC} & Access to raw ATM PVCs         &            \\
-       \macro{PF\_APPLETALK}& Appletalk                    & ddp(7)     \\
-       \macro{PF\_PACKET} & Low level packet interface     & packet(7)  \\    
+       \const{PF\_UNSPEC}   & 0& Non specificato               &            \\
+       \const{PF\_LOCAL}    & 1& Local communication           & unix(7)    \\
+       \const{PF\_UNIX}, \const{PF\_FILE}&1&Sinonimi di \const{PF\_LOCAL}& \\
+       \const{PF\_INET}     & 2& IPv4 Internet protocols       & ip(7)      \\
+       \const{PF\_AX25}     & 3& Amateur radio AX.25 protocol  &            \\
+       \const{PF\_IPX}      & 4& IPX - Novell protocols        &            \\
+       \const{PF\_APPLETALK}& 5& Appletalk                     & ddp(7)     \\
+       \const{PF\_NETROM}   & 6& Amateur radio NetROM          &            \\
+       \const{PF\_BRIDGE}   & 7& Multiprotocol bridge          &            \\
+       \const{PF\_ATMPVC}   & 8& Access to raw ATM PVCs        &            \\
+       \const{PF\_X25}      & 9& ITU-T X.25 / ISO-8208 protocol& x25(7)     \\
+       \const{PF\_INET6}    &10& IPv6 Internet protocols       & ipv6(7)    \\
+       \const{PF\_ROSE}     &11& Amateur Radio X.25 PLP        &            \\
+       \const{PF\_DECnet}   &12& Reserved for DECnet project   &            \\
+       \const{PF\_NETBEUI}  &13& Reserved for 802.2LLC project &            \\
+       \const{PF\_SECURITY} &14& Security callback pseudo AF   &            \\
+       \const{PF\_KEY}      &15& PF\_KEY key management API    &            \\
+       \const{PF\_NETLINK}  &16& Kernel user interface device  & netlink(7) \\
+       \const{PF\_ROUTE}    &16& Sinonimo di \const{PF\_NETLINK} emula BSD.&\\
+       \const{PF\_PACKET}   &17& Low level packet interface    & packet(7)  \\
+       \const{PF\_ASH}      &18& Ash                           &    \\
+       \const{PF\_ECONET}   &19& Acorn Econet                  &    \\
+       \const{PF\_ATMSVC}   &20& ATM SVCs                      &    \\
+       \const{PF\_SNA}      &22& Linux SNA Project             &    \\
+       \const{PF\_IRDA}     &23& IRDA socket                   &    \\
+       \const{PF\_PPPOX}    &24& PPPoX socket                  &    \\
+       \const{PF\_WANPIPE}  &25& Wanpipe API socket            &    \\
+       \const{PF\_LLC}      &26& Linux LLC                     &    \\
+       \const{PF\_BLUETOOTH}&31& Bluetooth socket              &    \\
        \hline
   \end{tabular}
        \hline
   \end{tabular}
-  \caption{Famiglie di protocolli definiti in Linux}
+  \caption{Famiglie di protocolli definiti in Linux.} 
   \label{tab:net_pf_names}
 \end{table}
 
   \label{tab:net_pf_names}
 \end{table}
 
-Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
-esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere
-creati solo da processi che hanno i privilegi di root (cioè effective uid
-uguale a zero) o la capability \macro{CAP\_NET\_RAW}.
-
-
-\subsection{Il tipo, o stile}
+% TODO aggiungere PF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25
+
+L'idea alla base della distinzione fra questi due insiemi di costanti era che
+una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
+il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
+il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
+quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
+famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
+nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
+valori numerici.\footnote{in Linux, come si può verificare andando a guardare
+  il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
+  e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
+  lo stesso nome.}
+
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+indirizzi, sono definiti dall'header \texttt{socket.h}. Un elenco delle
+famiglie di protocolli disponibili in Linux è riportato in
+tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
+  definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
+  compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
+  viene definita anche una costante \const{PF\_MAX} che indica il valore
+  massimo associabile ad un dominio (nel caso il suo valore 32).}
+
+Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
+dall'utente generico, ad esempio in generale tutti i socket di tipo
+\const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
+di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
+\itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
+
+
+\subsection{Il tipo di socket}
 \label{sec:sock_type}
 
 \label{sec:sock_type}
 
-La scelta di un dominio non comporta però la scelta dello stile di
-comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
-utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
-scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le
-glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
-glibc chiama \textit{styles}) definiti come \type{int} in \file{socket.h}:
-
-\begin{list}{}{}
-\item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati
+La scelta di un dominio non comporta però la scelta dello stile di
+comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
+utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
+socket permette di scegliere lo stile di comunicazione indicando il tipo di
+socket con l'argomento \param{type} di \func{socket}. Linux mette a
+disposizione vari tipi di socket (che corrispondono a quelli che il manuale
+della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
+seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
+  tre tipi, Linux supporta anche gli altri, come si può verificare nel file
+  \texttt{include/linux/net.h} dei sorgenti del kernel.}
+
+\begin{basedescript}{\desclabelwidth{2.9cm}\desclabelstyle{\nextlinelabel}}
+\item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
-  byte (da cui il nome \textit{stream}). 
-\item \macro{SOCK\_DGRAM} Viene usato per mandare pacchetti di lunghezza
-  massima fissata (\textit{datagram}) indirizzati singolarmente, senza
-  connessione e in maniera non affidabile. È l'opposto del precedente. 
-\item \macro{SOCK\_SEQPACKET} Provvede un canale di trasmissione di dati
+  byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
+  dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
+  urgenti (o \itindex{out-of-band} \textit{out-of-band}, vedi
+  sez.~\ref{sec:TCP_urgent_data}).
+\item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
+  (\textit{datagram}) di lunghezza massima prefissata, indirizzati
+  singolarmente. Non esiste una connessione e la trasmissione è effettuata in
+  maniera non affidabile.
+\item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
-  altro socket. I dati possono solo essere trasmessi e letti per pacchetti (di
-  dimensione massima fissata).
-\item \macro{SOCK\_RAW} Provvede l'accesso a basso livello ai protocolli di
+  altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
+  massima fissata, e devono essere letti integralmente da ciascuna chiamata a
+  \func{read}.
+\item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
   rete e alle varie interfacce. I normali programmi di comunicazione non
   rete e alle varie interfacce. I normali programmi di comunicazione non
-  devono usarlo.
-\item \macro{SOCK\_RDM} Provvede un canale di trasmissione di pacchetti
-  affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
-\item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato.
-\end{list}
-
-Si tenga presente che non tutte le combinazioni di famiglia di protocolli e
-tipo di socket sono valide, in quanto non è detto che nella famiglia esista un
-protocollo per tutti gli stili di comunicazione indicati qui sopra. Una
-tabella che mostra le combinazioni valide è la seguente:
+  devono usarlo, è riservato all'uso di sistema.
+\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
+  affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
+\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
+    pertanto non ne parleremo ulteriormente.}
+\end{basedescript}
+
+Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
+e un tipo di socket sono valide, in quanto non è detto che in una famiglia
+esista un protocollo per ciascuno dei diversi stili di comunicazione appena
+elencati.
 
 \begin{table}[htb]
   \footnotesize
   \centering
 
 \begin{table}[htb]
   \footnotesize
   \centering
-  \begin{tabular}{l|c|c|c|c|c|}
-   \multicolumn{1}{c}{} &\multicolumn{1}{c}{\macro{SOCK\_STREAM}}& 
-     \multicolumn{1}{c}{\macro{SOCK\_DGRAM}} & 
-     \multicolumn{1}{c}{\macro{SOCK\_RAW}} & 
-     \multicolumn{1}{c}{\macro{SOCK\_PACKET}}& 
-     \multicolumn{1}{c}{\macro{SOCK\_SEQPACKET}} \\
-     \cline{2-6}
-    \macro{PF\_UNIX}      &  si & si  &      &     &     \\
-     \cline{2-6}
-    \macro{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
-     \cline{2-6}
-    \macro{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
-     \cline{2-6}
-    \macro{PF\_IPX}       &     &     &      &     &     \\
-     \cline{2-6}
-    \macro{PF\_NETLINK}   &     &  si &  si  &     &     \\
-     \cline{2-6}
-    \macro{PF\_X25}       &     &     &      &     &  si \\
-     \cline{2-6}
-    \macro{PF\_AX25}      &     &     &      &     &     \\
-     \cline{2-6}
-    \macro{PF\_ATMPVC}    &     &     &      &     &     \\
-     \cline{2-6}
-    \macro{PF\_APPLETALK} &     & si  &  si  &     &     \\
-     \cline{2-6}
-    \macro{PF\_PACKET}    &     & si  & si   &     &     \\    
-     \cline{2-6}
+  \begin{tabular}{|l|c|c|c|c|c|}
+    \hline
+    \multicolumn{1}{|c|}{\textbf{Famiglia}}&
+    \multicolumn{5}{|c|}{\textbf{Tipo}}\\
+    \hline
+    \hline
+    &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM}     &\const{SOCK\_RAW}& 
+      \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\
+     \hline
+    \const{PF\_LOCAL}     &  si & si  &      &     &     \\
+     \hline
+%    \const{PF\_UNIX}&\multicolumn{5}{|l|}{sinonimo di \const{PF\_LOCAL}.}\\
+%     \hline
+    \const{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
+     \hline
+    \const{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
+     \hline
+    \const{PF\_IPX}       &     &     &      &     &     \\
+     \hline
+    \const{PF\_NETLINK}   &     &  si &  si  &     &     \\
+     \hline
+    \const{PF\_X25}       &     &     &      &     &  si \\
+     \hline
+    \const{PF\_AX25}      &     &     &      &     &     \\
+     \hline
+    \const{PF\_ATMPVC}    &     &     &      &     &     \\
+     \hline
+    \const{PF\_APPLETALK} &     & si  &  si  &     &     \\
+     \hline
+    \const{PF\_PACKET}    &     & si  & si   &     &     \\    
+     \hline
   \end{tabular}
   \caption{Combinazioni valide di dominio e tipo di protocollo per la 
     funzione \func{socket}.}
   \label{tab:sock_sock_valid_combinations}
 \end{table}
 
   \end{tabular}
   \caption{Combinazioni valide di dominio e tipo di protocollo per la 
     funzione \func{socket}.}
   \label{tab:sock_sock_valid_combinations}
 \end{table}
 
-Dove per ogni combinazione valida si è indicato il tipo di protocollo, o la
-parola \textsl{si} qualora non il protocollo non abbia un nome definito,
-mentre si sono lasciate vuote le caselle per le combinazioni non supportate.
-
+In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
+valide possibili per le principali famiglie di protocolli. Per ogni
+combinazione valida si è indicato il tipo di protocollo, o la parola
+\textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
+sono lasciate vuote le caselle per le combinazioni non supportate.
 
 
 \section{Le strutture degli indirizzi dei socket}
 \label{sec:sock_sockaddr}
 
 
 
 \section{Le strutture degli indirizzi dei socket}
 \label{sec:sock_sockaddr}
 
-Come si è visto nella creazione di un socket non si specifica nulla oltre al
+Come si è visto nella creazione di un socket non si specifica nulla oltre al
 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
 comunicazione.
 
 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
 comunicazione.
 
-Gli indirizzi vengono specificati attraverso apposite strutture che vengono
-utilizzate dalle altre funzioni della API dei socket quando la comunicazione
-viene effettivamente realizzata. 
-
-Ogni famiglia di protocolli ha ovviamente una sua forma di indirizzamento e in
-corrispondenza a questa una sua peculiare struttura degli indirizzi; i nomi di
-tutte queste strutture iniziano per \var{sockaddr\_}, quelli propri di
-ciascuna famiglia vengono identificati dal suffisso finale, aggiunto al nome
-precedente.
+Gli indirizzi infatti vengono specificati attraverso apposite strutture che
+vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
+la comunicazione viene effettivamente realizzata.  Ogni famiglia di protocolli
+ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
+sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
+iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
+identificati dal suffisso finale, aggiunto al nome precedente.
 
 
 \subsection{La struttura generica}
 \label{sec:sock_sa_gen}
 
 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
 
 
 \subsection{La struttura generica}
 \label{sec:sock_sa_gen}
 
 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
-attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
+attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 nelle varie famiglie di protocolli; questo pone il problema di come passare
 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 nelle varie famiglie di protocolli; questo pone il problema di come passare
-questi puntatori, il C ANSI risolve questo problema coi i puntatori generici
-(i \type{void *}), ma l'interfaccia dei socket è antecedente alla
-definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
-una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata
-in \nfig:
+questi puntatori, il C moderno risolve questo problema coi i puntatori
+generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
+definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
+una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
+è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
 
 \begin{figure}[!htb]
 
 \begin{figure}[!htb]
-  \footnotesize
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-struct sockaddr {
-    sa_family_t  sa_family;     /* address family: AF_xxx */
-    char         sa_data[14];   /* address (protocol-specific) */
-};
-  \end{lstlisting}
-  \caption{La struttura generica degli indirizzi dei socket \type{sockaddr}}
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/sockaddr.h}
+  \end{minipage} 
+  \caption{La struttura generica degli indirizzi dei socket
+    \structd{sockaddr}.} 
   \label{fig:sock_sa_gen_struct}
 \end{figure}
 
 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
 prototipo un puntatore a questa struttura; per questo motivo quando si
 invocano dette funzioni passando l'indirizzo di un protocollo specifico
   \label{fig:sock_sa_gen_struct}
 \end{figure}
 
 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
 prototipo un puntatore a questa struttura; per questo motivo quando si
 invocano dette funzioni passando l'indirizzo di un protocollo specifico
-occorrerà eseguire un casting del relativo puntatore.
+occorrerà eseguire una conversione del relativo puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
-POSIX.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
-definiti; la struttura è invece definita nell'include file
-\file{sys/socket.h}
+POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
+rispettivi file di include in cui sono definiti; la struttura è invece
+definita nell'include file \file{sys/socket.h}.
 
 \begin{table}[!htb]
   \centering
 
 \begin{table}[!htb]
   \centering
+  \footnotesize
   \begin{tabular}{|l|l|l|}
     \hline
     \multicolumn{1}{|c|}{\textbf{Tipo}}& 
   \begin{tabular}{|l|l|l|}
     \hline
     \multicolumn{1}{|c|}{\textbf{Tipo}}& 
@@ -345,182 +411,325 @@ definiti; la struttura 
     \hline
     \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
     \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
     \hline
     \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
     \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
-    un socket& \type{sys/socket.h}\\
+    un socket& \file{sys/socket.h}\\
     \hline
     \hline
-    \type{in\_addr\_t} & indirizzo IPv4 (\file{uint32\_t}) & 
-    \type{netinet/in.h}\\
-    \type{in\_port\_t} & porta TCP o UDP (\file{uint16\_t})& 
-    \type{netinet/in.h}\\
+    \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & 
+    \file{netinet/in.h}\\
+    \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& 
+    \file{netinet/in.h}\\
     \hline
   \end{tabular}
   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 
     \hline
   \end{tabular}
   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 
-    stabilito dallo standard POSIX.1g}
+    stabilito dallo standard POSIX.1g.}
   \label{tab:sock_data_types}
 \end{table}
 
   \label{tab:sock_data_types}
 \end{table}
 
-In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
-aggiuntivo \var{uint8\_t sin\_len} (come riportato da R. Stevens nei suoi
-libri). Questo campo non verrebbe usato direttamente dal programmatore e non è
-richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il campo
-\type{sa\_family\_t} era storicamente un \type{unsigned short}.
+In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
+aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
+\cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
+non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
+campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
 
 
-Dal punto di vista del programmatore l'unico uso di questa struttura è quello
+Dal punto di vista del programmatore l'unico uso di questa struttura è quello
 di fare da riferimento per il casting, per il kernel le cose sono un po'
 diverse, in quanto esso usa il puntatore per recuperare il campo
 di fare da riferimento per il casting, per il kernel le cose sono un po'
 diverse, in quanto esso usa il puntatore per recuperare il campo
-\var{sa\_family} con cui determinare il tipo di indirizzo; per questo
-motivo, anche se l'uso di un puntatore \type{void *} sarebbe più immediato
-per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto
-l'uso di questa struttura.
+\var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
+indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
+sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
+è stato mantenuto l'uso di questa struttura.
 
 
 \subsection{La struttura degli indirizzi IPv4}
 \label{sec:sock_sa_ipv4}
 
 
 
 \subsection{La struttura degli indirizzi IPv4}
 \label{sec:sock_sa_ipv4}
 
-I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione
-attraverso internet; la struttura per gli indirizzi per un socket internet
-(IPv4) è definita come \type{sockaddr\_in} nell'header file
-\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
-conforme allo standard POSIX.1g.
+I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
+attraverso internet; la struttura per gli indirizzi per un socket internet (se
+si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
+\file{netinet/in.h} ed ha la forma mostrata in
+fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
 \begin{figure}[!htb]
 
 \begin{figure}[!htb]
-  \footnotesize
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-struct sockaddr_in {
-    sa_family_t     sin_family; /* address family: AF_INET */
-    u_int16_t       sin_port;   /* port in network byte order */
-    struct in_addr  sin_addr;   /* internet address */
-};
-/* Internet address. */
-struct in_addr {
-    u_int32_t       s_addr;     /* address in network byte order */
-};
-  \end{lstlisting}
-  \caption{La struttura degli indirizzi dei socket internet (IPv4)
-    \type{sockaddr\_in}.}
+  \footnotesize\centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/sockaddr_in.h}
+  \end{minipage} 
+  \caption{La struttura \structd{sockaddr\_in} degli indirizzi dei socket
+    internet (IPv4) e la struttura \structd{in\_addr} degli indirizzi IPv4.}
   \label{fig:sock_sa_ipv4_struct}
 \end{figure}
 
 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
   \label{fig:sock_sa_ipv4_struct}
 \end{figure}
 
 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
-internet di un'interfaccia più un numero di porta. Il protocollo IP non
-prevede numeri di porta, che sono utilizzati solo dai protocolli di livello
-superiore come TCP e UDP. Questa struttura però viene usata anche per i socket
-RAW che accedono direttamente al livello di IP, nel qual caso il numero della
-porta viene settato al numero di protocollo.
-
-Il membro \var{sin\_family} deve essere sempre settato; \var{sin\_port}
-specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; i numeri di
-porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da
-servizi standard. Soltanto processi con i privilegi di root (effective uid
-uguale a zero) o con la capability \macro{CAP\_NET\_BIND\_SERVICE} possono
-usare la funzione \func{bind} su queste porte.
-
-Il membro \var{sin\_addr} contiene l'indirizzo internet dell'altro capo
-della comunicazione, e viene acceduto sia come struttura (un resto di una
-implementazione precedente in cui questa era una \texttt{union} usata per
-accedere alle diverse classi di indirizzi) che come intero.
-
-Infine è da sottolineare che sia gli indirizzi che i numeri di porta devono
-essere specificati in quello che viene chiamato \textit{network order}, cioè
+internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
+dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}).  Il
+protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
+protocolli di livello superiore come TCP e UDP. Questa struttura però viene
+usata anche per i socket RAW che accedono direttamente al livello di IP, nel
+qual caso il numero della porta viene impostato al numero di protocollo.
+
+Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
+altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
+specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
+chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
+soltanto processi con i privilegi di amministratore (con user-ID effettivo
+uguale a zero) o con la \itindex{capabilities} \textit{capability}
+\const{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \func{bind} (che
+vedremo in sez.~\ref{sec:TCP_func_bind}) su queste porte.
+
+Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
+come struttura (un resto di una implementazione precedente in cui questa era
+una \direct{union} usata per accedere alle diverse classi di indirizzi) che
+direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
+costanti che identificano alcuni indirizzi speciali, riportati in
+tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
+
+Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
+essere specificati in quello che viene chiamato \textit{network order}, cioè
 con i bit ordinati in formato \textit{big endian}, questo comporta la
 con i bit ordinati in formato \textit{big endian}, questo comporta la
-necessità di usare apposite funzioni di conversione per mantenere la
-portabilità del codice (vedi \secref{sec:sock_addr_func} per i dettagli del
+necessità di usare apposite funzioni di conversione per mantenere la
+portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
 problema e le relative soluzioni).
 
 
 \subsection{La struttura degli indirizzi IPv6}
 \label{sec:sock_sa_ipv6}
 
 problema e le relative soluzioni).
 
 
 \subsection{La struttura degli indirizzi IPv6}
 \label{sec:sock_sa_ipv6}
 
-Essendo IPv6 un'estensione di IPv4 i socket di tipo \macro{PF\_INET6} sono
+Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
 sostanzialmente identici ai precedenti; la parte in cui si trovano
 sostanzialmente identici ai precedenti; la parte in cui si trovano
-praticamente tutte le differenze è quella della struttura degli indirizzi. La
-struttura degli indirizzi è definita ancora in \file{netinet/in.h}.
+praticamente tutte le differenze fra i due socket è quella della struttura
+degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
+in fig.~\ref{fig:sock_sa_ipv6_struct}.
 
 \begin{figure}[!htb]
 
 \begin{figure}[!htb]
-  \footnotesize
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-struct sockaddr_in6 {
-    u_int16_t       sin6_family;   /* AF_INET6 */
-    u_int16_t       sin6_port;     /* port number */
-    u_int32_t       sin6_flowinfo; /* IPv6 flow information */
-    struct in6_addr sin6_addr;     /* IPv6 address */
-    u_int32_t       sin6_scope_id; /* Scope id (new in 2.4) */
-};
-
-struct in6_addr {
-    unsigned char   s6_addr[16];   /* IPv6 address */
-};
-  \end{lstlisting}
-  \caption{La struttura degli indirizzi dei socket IPv6 
-    \type{sockaddr\_in6}.}
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/sockaddr_in6.h}
+  \end{minipage} 
+  \caption{La struttura \structd{sockaddr\_in6} degli indirizzi dei socket
+    IPv6 e la struttura \structd{in6\_addr} degli indirizzi IPv6.}
   \label{fig:sock_sa_ipv6_struct}
 \end{figure}
 
   \label{fig:sock_sa_ipv6_struct}
 \end{figure}
 
-Il campo \var{sin6\_family} deve essere sempre settato ad
-\macro{AF\_INET6}, il campo \var{sin6\_port} è analogo a quello di IPv4 e
-segue le stesse regole; il campo \var{sin6\_flowinfo} è a sua volta diviso
-in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i
-successivi 4 bit la priorità e gli ultimi 4 sono riservati; questi valori
-fanno riferimento ad alcuni campi specifici dell'header dei pacchetti IPv6
-(vedi \secref{sec:IP_ipv6head}) ed il loro uso è sperimentale.
+Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
+il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
+il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
+bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
+gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
+specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed
+il loro uso è sperimentale.
 
 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
 
 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
-infine il campo \var{sin6\_scope\_id} è un campo introdotto con il kernel
-2.4 per gestire alcune operazioni riguardanti il multicasting.
-Si noti che questa struttura è più grande di una \var{sockaddr} generica,
-quindi occorre stare attenti a non avere fatto assunzioni riguardo alla
-possibilità di contenere i dati nelle dimensioni di quest'ultima.
+espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
+campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni
+riguardanti il \itindex{multicast} \textit{multicasting}.  Si noti infine che
+\struct{sockaddr\_in6} ha una dimensione maggiore della struttura
+\struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi
+occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
+di contenere i dati nelle dimensioni di quest'ultima.
 
 
 \subsection{La struttura degli indirizzi locali}
 \label{sec:sock_sa_local}
 
 
 
 \subsection{La struttura degli indirizzi locali}
 \label{sec:sock_sa_local}
 
-I socket di tipo \macro{PF\_UNIX} vengono usati per una comunicazione
-efficiente fra processi che stanno sulla stessa macchina; essi rispetto ai
-precedenti possono essere anche creati in maniera anonima attraverso la
-funzione \func{socketpair}. Quando però si vuole fare riferimento esplicito
-ad uno di questi socket si deve usare la seguente struttura di indirizzi
-definita nel file di header \file{sys/un.h}.
+I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
+comunicazione fra processi che stanno sulla stessa macchina (per questo
+vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
+hanno la caratteristica ulteriore di poter essere creati anche in maniera
+anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
+sez.~\ref{sec:ipc_socketpair}).  Quando però si vuole fare riferimento
+esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
+di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
+fig.~\ref{fig:sock_sa_local_struct}.
 
 \begin{figure}[!htb]
 
 \begin{figure}[!htb]
-  \footnotesize
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-#define UNIX_PATH_MAX    108
-struct sockaddr_un {
-    sa_family_t  sun_family;              /* AF_UNIX */
-    char         sun_path[UNIX_PATH_MAX]; /* pathname */
-};
-  \end{lstlisting}
-  \caption{La struttura degli indirizzi dei socket locali 
-    \var{sockaddr\_un}.}
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/sockaddr_un.h}
+  \end{minipage} 
+  \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
+    locali (detti anche \textit{unix domain}) definita in \file{sys/un.h}.}
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
-In questo caso il campo \var{sun\_family} deve essere \macro{AF\_UNIX},
-mentre il campo \var{sun\_path} deve specificare un indirizzo; questo ha
-due forme un file (di tipo socket) nel filesystem o una stringa univoca
-(tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
+In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
+il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
+può essere un file (di tipo socket) nel filesystem o una stringa univoca
+(mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
 specificato come una stringa (terminata da uno zero) corrispondente al
 specificato come una stringa (terminata da uno zero) corrispondente al
-pathname del file; nel secondo invece \var{sun\_path} inizia con uno zero
-vengono usati i restanti byte come stringa (senza terminazione).
+\itindex{pathname} \textit{pathname} del file; nel secondo invece
+\var{sun\_path} inizia con uno zero e vengono usati come nome i restanti byte
+come stringa, senza terminazione.
+
+
+\subsection{La struttura degli indirizzi AppleTalk}
+\label{sec:sock_sa_appletalk}
+
+I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
+\file{netatalk} per implementare la comunicazione secondo il protocollo
+AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
+computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
+kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
+opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
+questo argomento principalmente per mostrare l'uso di un protocollo
+alternativo.
+
+I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
+a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
+\func{socket} deve essere nullo. È altresì possibile usare i socket raw
+specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
+per \param{protocol} è \const{ATPROTO\_DDP}.
+
+Gli indirizzi AppleTalk devono essere specificati tramite una struttura
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
+fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
+il file \file{netatalk/at.h}.
 
 
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/sockaddr_atalk.h}
+  \end{minipage} 
+  \caption{La struttura \structd{sockaddr\_atalk} degli indirizzi dei socket
+    AppleTalk, e la struttura \structd{at\_addr} degli indirizzi AppleTalk.}
+  \label{fig:sock_sa_atalk_struct}
+\end{figure}
 
 
-% \subsection{Il passaggio delle strutture}
-% \label{sec:sock_addr_pass}
+Il campo \var{sat\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
+campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
+inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
+usati solo da processi con i privilegi di amministratore o con la
+\itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
+L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
+essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+valore \const{AT\_ANYNET}, che indica una rete generica e vale anche per
+indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
+può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
+corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
+rete.
+
+
+\subsection{La struttura degli indirizzi dei \textit{packet socket}}
+\label{sec:sock_sa_packet}
+
+I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
+un'interfaccia specifica di Linux per inviare e ricevere pacchetti
+direttamente su un'interfaccia di rete, senza passare per le funzioni di
+gestione dei protocolli di livello superiore. In questo modo è possibile
+implementare dei protocolli in user space, agendo direttamente sul livello
+fisico. In genere comunque si preferisce usare la libreria
+\file{pcap},\footnote{la libreria è mantenuta insieme al comando
+  \cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
+  progetto \href{http://www.tcpdump.org/}{\textsf{http://www.tcpdump.org/}}.}
+che assicura la portabilità su altre piattaforme, anche se con funzionalità
+ridotte.
+
+Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
+Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
+collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
+del dispositivo e viceversa.  In questo modo, in fase di trasmissione, il
+contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
+fornito dall'utente. In fase di ricezione invece tutto il contenuto del
+pacchetto viene passato inalterato sul socket, anche se il kernel analizza
+comunque il pacchetto, riempiendo gli opportuni campi della struttura
+\struct{sockaddr\_ll} ad esso associata.
+
+Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
+livello di rete. In questo caso in fase di ricezione l'intestazione del
+protocollo di collegamento viene rimossa prima di passare il resto del
+pacchetto all'utente, mentre in fase di trasmissione viene creata una
+opportuna intestazione per il protocollo a livello di collegamento
+utilizzato, usando le informazioni necessarie che devono essere specificate
+sempre con una struttura \struct{sockaddr\_ll}.
+
+Nella creazione di un \textit{packet socket} il valore dell'argomento
+\param{protocol} di \func{socket} serve a specificare, in \textit{network
+  order}, il numero identificativo del protocollo di collegamento si vuole
+utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
+quelli disponibili in Linux sono accessibili attraverso opportune costanti
+simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
+speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
+pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
+di questi socket è una operazione privilegiata e può essere effettuati solo da
+un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
+la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
+
+Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
+specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
+provengono; se si vuole limitare il passaggio ad una interfaccia specifica
+occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
 
 
-% Come detto nelle funzioni della API dei socket le strutture degli indirizzi
-% vengono sempre passate per riferimento usando un puntatore; anche la lunghezza
-% della struttura è passata come argomento, ma in questo caso la modalità del
-% passaggio dipende dalla direzione del medesimo, dal processo al kernel o
-% viceversa.
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/sockaddr_ll.h}
+  \end{minipage} 
+  \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
+    \textit{packet socket}.}
+  \label{fig:sock_sa_packet_struct}
+\end{figure}
 
 
-% In particolare le tre funzioni \texttt{bind}, \texttt{connect} e
-% \texttt{sendto} passano la struttura al kernel, in questo caso è passata
-% \textsl{per valore} anche la dimensione della medesima
+Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
+\struct{sockaddr\_ll}, e la sua definizione è riportata in
+fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
+leggermente diverso rispetto a quanto visto finora per gli altri tipi di
+socket.  Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
+scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
+specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
+tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
+al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
+entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
+pacchetto.
+
+Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
+\const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
+e deve essere indicato in \textit{network order}, facendo uso delle costanti
+simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
+l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
+stesso tipo (se ad esempio si hanno più schede ethernet), permette di
+selezionare quella con cui si vuole operare (un valore nullo indica qualunque
+interfaccia).  Questi sono i due soli campi che devono essere specificati
+quando si vuole selezionare una interfaccia specifica, usando questa struttura
+con la funzione \func{bind}.
+
+I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
+l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
+relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
+collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il
+MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
+ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
+pacchetti, in questo caso tutti gli altri campi devono essere nulli.
+
+Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
+\file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
+pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
+senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
+seguenti valori: \const{PACKET\_HOST} per un pacchetto indirizzato alla
+macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di
+\itindex{broadcast} \textit{broadcast}, \const{PACKET\_MULTICAST} per un
+pacchetto inviato ad un indirizzo fisico di \itindex{multicast}
+\textit{multicast}, \const{PACKET\_OTHERHOST} per un pacchetto inviato ad
+un'altra stazione (e ricevuto su un'interfaccia in \index{modo~promiscuo} modo
+promiscuo), \const{PACKET\_OUTGOING} per un pacchetto originato dalla propria
+macchina che torna indietro sul socket.
+
+
+Si tenga presente infine che in fase di ricezione, anche se si richiede il
+troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
+\func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
+lunghezza effettiva del pacchetto così come arrivato sulla linea.
+
+%% \subsection{La struttura degli indirizzi DECnet}
+%% \label{sec:sock_sa_decnet}
+%% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
+%% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
+%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
+%% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
+%% solo come esempio 
 
 
 
 
-% Le funzioni \texttt{accept}, \texttt{recvfrom}, \texttt{getsockname} e
-% \texttt{getpeername} invece ricevono i valori del kernel 
+% TODO: trattare i socket RDS, vedi documentazione del kernel, file 
+% Documentation/networking/rds.txt
 
 
 
 
 
 
@@ -528,92 +737,156 @@ vengono usati i restanti byte come stringa (senza terminazione).
 \label{sec:sock_addr_func}
 
 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
 \label{sec:sock_addr_func}
 
 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
-indirizzi, limitandoci però agli indirizzi internet.
-
-Come accennato gli indirizzi e i numeri di porta usati nella rete devono
-essere forniti in formato opportuno (il \textit{network order}). Per capire
-cosa significa tutto ciò occorre introdurre un concetto generale che tornerà
-utile anche in seguito.
+indirizzi, limitandoci però agli indirizzi internet.  Come accennato gli
+indirizzi e i numeri di porta usati nella rete devono essere forniti in
+formato opportuno (il \textit{network order}). Per capire cosa significa tutto
+ciò occorre introdurre un concetto generale che tornerà utile anche in
+seguito.
 
 
 \subsection{La \textit{endianess}}
 \label{sec:sock_endianess}
 
 
 
 \subsection{La \textit{endianess}}
 \label{sec:sock_endianess}
 
-La rappresentazione di un numero binario in un computer può essere fatta in
+\itindbeg{endianess}
+La rappresentazione di un numero binario in un computer può essere fatta in
 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
   endian} a seconda di come i singoli bit vengono aggregati per formare le
 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
   endian} a seconda di come i singoli bit vengono aggregati per formare le
-variabili intere (in diretta corrispondenza a come sono poi in realtà cablati
-sui bus interni del computer).
-
-Per capire meglio il problema si consideri un intero a 16 bit scritto in una
-locazione di memoria posta ad un certo indirizzo. I singoli bit possono essere
-disposti un memoria in due modi, a partire dal più significativo o a partire
-dal meno significativo. Così nel primo caso si troverà il byte che contiene i
-bit più significativi all'indirizzo menzionato e il byte con i bit meno
-significativi nell'indirizzo successivo; questo ordinamento è detto
-\textit{little endian} dato che il dato finale è la parte ``piccola'' del
-numero. Il caso opposto, in cui si parte dal bit meno significativo è detto
-per lo stesso motivo \textit{big endian}.
+variabili intere (ed in genere in diretta corrispondenza a come sono poi in
+realtà cablati sui bus interni del computer).
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[height=3cm]{img/endianess}
+  \caption{Schema della disposizione dei dati in memoria a seconda della
+    \textit{endianess}.}
+  \label{fig:sock_endianess}
+\end{figure}
+
+Per capire meglio il problema si consideri un intero a 32 bit scritto in una
+locazione di memoria posta ad un certo indirizzo. Come illustrato in
+fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
+in due modi: a partire dal più significativo o a partire dal meno
+significativo.  Così nel primo caso si troverà il byte che contiene i bit più
+significativi all'indirizzo menzionato e il byte con i bit meno significativi
+nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
+dato che si trova per prima la parte più grande. Il caso opposto, in cui si
+parte dal bit meno significativo è detto per lo stesso motivo \textit{little
+  endian}.
+
+Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+computer con un programma elementare che si limita ad assegnare un valore ad
+una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
+Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
+allora se lo eseguiamo su un PC otterremo:
+\begin{verbatim}
+[piccardi@gont sources]$ ./endtest
+Using value ABCDEF01
+val[0]= 1
+val[1]=EF
+val[2]=CD
+val[3]=AB
+\end{verbatim}%$
+mentre su di un Mac avremo:
+\begin{verbatim}
+piccardi@anarres:~/gapil/sources$ ./endtest
+Using value ABCDEF01
+val[0]=AB
+val[1]=CD
+val[2]=EF
+val[3]= 1
+\end{verbatim}%$
+
 
 La \textit{endianess} di un computer dipende essenzialmente dalla architettura
 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
 
 La \textit{endianess} di un computer dipende essenzialmente dalla architettura
 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
-formato della rete è anch'esso \textit{big endian}, altri esempi sono quello
-del bus PC, che è \textit{little endian}, o quello del bus VME che è
-\textit{big endian}.
+formato dei dati contenuti nelle intestazioni dei protocolli di rete è
+anch'esso \textit{big endian}; altri esempi di uso di questi due diversi
+formati sono quello del bus PCI, che è \textit{little endian}, o quello del
+bus VME che è \textit{big endian}.
 
 Esistono poi anche dei processori che possono scegliere il tipo di formato
 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
 
 Esistono poi anche dei processori che possono scegliere il tipo di formato
 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
-in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
+in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
 questi cambiamenti.
 
 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
 questi cambiamenti.
 
+\begin{figure}[htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includecodesample{listati/endian.c}
+  \end{minipage} 
+  \normalsize
+  \caption{La funzione \func{endian}, usata per controllare il tipo di
+    architettura della macchina.}
+  \label{fig:sock_endian_code}
+\end{figure}
+
+Per controllare quale tipo di ordinamento si ha sul proprio computer si è
+scritta una piccola funzione di controllo, il cui codice è riportato
+fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
+l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
+è \textit{little endian}.
+
+Come si vede la funzione è molto semplice, e si limita, una volta assegnato
+(\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
+di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
+Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
+accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
+  11}) il valore della seconda assumendo che il primo byte sia quello meno
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+\textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
+il valore del confronto delle due variabili. 
+\itindend{endianess}
+
+
+
 \subsection{Le funzioni per il riordinamento}
 \label{sec:sock_func_ord}
 
 \subsection{Le funzioni per il riordinamento}
 \label{sec:sock_func_ord}
 
-Il problema connesso all'endianess è che quando si passano dei dati da un tipo
-di architettura all'altra i dati vengono interpretati in maniera diversa, e ad
-esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è
-suddiviso scambiati di posto, e ne sarà quindi invertito l'ordine di lettura
-per cui, per riavere il valore originale dovranno essere rovesciati.
-
-Per questo motivo si usano le seguenti funzioni di conversione che servono a
-tener conto automaticamente della possibile differenza fra l'ordinamento usato
-sul computer e quello che viene usato nelle trasmissione sulla rete; queste
-funzioni sono:
-\begin{prototype}{netinet/in.h}
-{unsigned long int htonl(unsigned long int hostlong)} 
-  Converte l'intero a 32 bit \var{hostlong} dal formato della macchina a
+Il problema connesso \itindex{endianess} all'endianess è che quando si passano
+dei dati da un tipo di architettura all'altra i dati vengono interpretati in
+maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
+con i due byte in cui è suddiviso scambiati di posto.  Per questo motivo si
+usano delle funzioni di conversione che servono a tener conto automaticamente
+della possibile differenza fra l'ordinamento usato sul computer e quello che
+viene usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
+\funcd{htons}, \funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{netinet/in.h}
+  \funcdecl{unsigned long int htonl(unsigned long int hostlong)} 
+  Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
   quello della rete.
   quello della rete.
-\end{prototype}
-\begin{prototype}{netinet/in.h}
-{unsigned short int htons(unsigned short int hostshort)}
-  Converte l'intero a 16 bit \var{hostshort} dal formato della macchina a
+  \funcdecl{unsigned short int htons(unsigned short int hostshort)}
+  Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
   quello della rete.
   quello della rete.
-\end{prototype}
-\begin{prototype}{netinet/in.h}
-{unsigned long int ntonl(unsigned long int netlong)}
-  Converte l'intero a 32 bit \var{netlong} dal formato della rete a quello
+
+  \funcdecl{unsigned long int ntohl(unsigned long int netlong)}
+  Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
   della macchina.
   della macchina.
-\end{prototype}
-\begin{prototype}{netinet/in.h}
-{unsigned sort int ntons(unsigned short int netshort)}
-  Converte l'intero a 16 bit \var{netshort} dal formato della rete a quello
+
+  \funcdecl{unsigned sort int ntohs(unsigned short int netshort)}
+  Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
   della macchina.
   della macchina.
-\end{prototype}
+  
+  \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non
+    prevedono errori.}
+\end{functions}
+
 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
-indicare i tipi di dato (\type{long} o \type{short}, riportati anche dai
+indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
 prototipi).
 
 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
 macchina che si sta usando abbia una architettura \textit{big endian} queste
 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
 prototipi).
 
 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
 macchina che si sta usando abbia una architettura \textit{big endian} queste
 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
-assicurare la portabilità del codice su tutte le architetture.
+assicurare la portabilità del codice su tutte le architetture.
 
 
 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e 
 
 
 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e 
@@ -621,454 +894,156 @@ assicurare la portabilit
 \label{sec:sock_func_ipv4}
 
 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
 \label{sec:sock_func_ipv4}
 
 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
-binario usato nelle strutture degli indirizzi alla rappresentazione dei numeri
-IP che si usa normalmente.
+binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
+dei numeri IP che si usa normalmente.
 
 Le prime tre funzioni di manipolazione riguardano la conversione degli
 
 Le prime tre funzioni di manipolazione riguardano la conversione degli
-indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
-cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
-\texttt{192.160.0.1}) al formato binario (direttamente in \textit{network
+indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
+cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
+\texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
   order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
   order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
-mnemonico per indicare la stringa. Dette funzioni sono:
-\begin{prototype}{arpa/inet.h}
-  {int inet\_aton(const char *src, struct in\_addr *dest)} 
-  Converte la stringa puntata da \var{src} nell'indirizzo binario da
-  memorizzare all'indirizzo puntato da \var{dest}, restituendo 0 in caso di
-  successo e 1 in caso di fallimento (è espressa in questa forma in modo da
-  poterla usare direttamente con il puntatore usato per passare la struttura
-  degli indirizzi). Se usata con \var{dest} inizializzato a \macro{NULL}
-  effettua la validazione dell'indirizzo.
-\end{prototype}
-\begin{prototype}{arpa/inet.h}{in\_addr\_t inet\_addr(const char *strptr)}
-  Restituisce l'indirizzo a 32 bit in network order a partire dalla stringa
-  passata come parametro, in caso di errore restituisce il valore
-  \macro{INADDR\_NONE} che tipicamente sono trentadue bit a uno; questo
-  comporta che la stringa \texttt{255.255.255.255}, che pure è un indirizzo
-  valido, non può essere usata con questa funzione; per questo motivo essa è
-  generalmente deprecata in favore della precedente.
-\end{prototype}  
-\begin{prototype}{arpa/inet.h}{char *inet\_ntoa(struct in\_addr addrptr)}
-  Converte il valore a 32 bit dell'indirizzo (espresso in \textit{network
-    order}) restituendo il puntatore alla stringa che contiene l'espressione
-  in formato dotted decimal. Si deve tenere presente che la stringa risiede in
-  memoria statica, per cui questa funzione non è rientrante.
-\end{prototype}
+mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
+\funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{arpa/inet.h}
+  
+  \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
+  dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
+
+  \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
+  la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
+
+  \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
+  Converte un indirizzo IP in una stringa \textit{dotted decimal}.
+
+  \bodydesc{Tutte queste le funzioni non generano codice di errore.}
+\end{functions}
+
+La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
+network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
+nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
+un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
+tipicamente sono trentadue bit a uno.  Questo però comporta che la stringa
+\texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
+con questa funzione; per questo motivo essa è generalmente deprecata in favore
+di \func{inet\_aton}.
+
+La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
+nell'indirizzo binario che viene memorizzato nell'opportuna struttura
+\struct{in\_addr} (si veda fig.~\ref{fig:sock_sa_ipv4_struct}) situata
+all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
+modo da poterla usare direttamente con il puntatore usato per passare la
+struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
+in caso di fallimento.  Se usata con \param{dest} inizializzato a \val{NULL}
+effettua la validazione dell'indirizzo.
+
+L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
+dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
+alla stringa che contiene l'espressione in formato dotted decimal. Si deve
+tenere presente che la stringa risiede in memoria statica, per cui questa
+funzione non è \index{funzioni!rientranti} rientrante.
 
 
 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
 \label{sec:sock_conv_func_gen}
 
 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
 
 
 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
 \label{sec:sock_conv_func_gen}
 
 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
-motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
+motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
 e \textit{numeric}.
 
 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
 e \textit{numeric}.
 
-% \begin{figure}[htb]
-%   \centering  
-
-%   \caption{Schema della rappresentazioni utilizzate dalle funzioni di 
-%     conversione \texttt{inet\_pton} e \texttt{inet\_ntop} }
-%   \label{fig:sock_inet_conv_func}
-
-% \end{figure}
-
 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
-indirizzo e può essere \macro{AF\_INET} o \macro{AF\_INET6}. Se la famiglia
-indicata non è valida entrambe le funzioni settano la variabile \var{errno}
-al valore \macro{EAFNOSUPPORT}. I prototipi delle suddette funzioni sono i
-seguenti:
+indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
+prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
+indirizzo; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
 \begin{prototype}{sys/socket.h}
-  {int inet\_pton(int af, const char *src, void *addr\_ptr)} Converte la
-  stringa puntata da \var{src} nell'indirizzo IP da memorizzare
-  all'indirizzo puntato da \var{addr\_ptr}, la funzione restituisce un
-  valore positivo in caso di successo, e zero se la stringa non rappresenta un
-  indirizzo valido, e negativo se \var{af} specifica una famiglia di indirizzi
-  non valida.
+{int inet\_pton(int af, const char *src, void *addr\_ptr)} 
+
+  Converte l'indirizzo espresso tramite una stringa nel valore numerico.
+  
+  \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
+    una famiglia di indirizzi non valida, con \var{errno} che assume il valore
+    \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
+    indirizzo valido, ed un valore positivo in caso di successo.}
 \end{prototype}
 \end{prototype}
+
+La funzione converte la stringa indicata tramite \param{src} nel valore
+numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
+memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
+restituisce un valore positivo in caso di successo, nullo se la stringa non
+rappresenta un indirizzo valido, e negativo se \param{af} specifica una
+famiglia di indirizzi non valida.
+
+La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
+indirizzo in una stringa; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
   {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
 \begin{prototype}{sys/socket.h}
   {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
-  Converte la struttura dell'indirizzo puntata da \var{addr\_ptr} in una
-  stringa che viene copiata nel buffer puntato dall'indirizzo \var{dest};
-  questo deve essere preallocato dall'utente e la lunghezza deve essere almeno
-  \macro{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
-  \macro{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
-  comunque venire specificata attraverso il parametro \var{len}.
+  Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
  
  
-  \bodydesc{La funzione restituisce un puntatore non nullo a \var{dest} in
-    caso di successo e un puntatore nullo in caso di fallimento, in
-    quest'ultimo caso viene settata la variabile \var{errno} con il valore
-    \macro{ENOSPC} in caso le dimensioni dell'indirizzo eccedano la lunghezza
-    specificata da \var{len} o \macro{ENOAFSUPPORT} in caso \var{af} non sia
-    una famiglia di indirizzi valida.}
+  \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
+    convertita in caso di successo e \val{NULL} in caso di fallimento, nel
+    qual caso \var{errno} assume i valori: 
+    \begin{errlist}
+    \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
+      dell'indirizzo eccedono la lunghezza specificata da \param{len}.
+    \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
+      una valida.
+  \end{errlist}}
 \end{prototype}
 
 \end{prototype}
 
-Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
-(\var{struct  in\_addr} per IPv4, e \var{struct  in6\_addr} per IPv6), che
-devono essere precedentemente allocate e passate attraverso il puntatore
-\var{addr\_ptr}; il parametro \var{dest} di \func{inet\_ntop} non può essere
-nullo e deve essere allocato precedentemente.
-
-Il formato usato per gli indirizzi in formato di presentazione è la notazione
-\textit{dotted decimal} per IPv4 e quella descritta in
-\secref{sec:IP_ipv6_notation} per IPv6.
-
-
-
-\section{Un esempio di applicazione}
-\label{sec:sock_appplication}
-
-Per evitare di rendere questa introduzione ai socket puramente teorica
-iniziamo con il mostrare un esempio di un client TCP elementare.  Prima di
-passare agli esempi del client e del server, esamineremo una caratteristica
-delle funzioni di I/O sui socket che ci tornerà utile anche in seguito.
-
+La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
+in una stringa che viene copiata nel buffer puntato dall'indirizzo
+\param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
+essere almeno \const{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
+\const{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
+comunque venire specificata attraverso il parametro \param{len}.
 
 
-\subsection{Il comportamento delle funzioni di I/O}
-\label{sec:sock_io_behav}
-
-Una cosa di cui non sempre si è consapevoli quando si ha a che fare con i
-socket è che le funzioni di input/output non sempre hanno lo stesso
-comportamento che avrebbero con i normali files (in particolare questo accade
-per i socket di tipo stream). 
-
-Infatti con i socket è comune che funzioni come \func{read} o \func{write}
-possano restituire in input o scrivere in output un numero di byte minore di
-quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
-comportamento normale anche per l'I/O su file, e succede
-perché si eccede in lettura o scrittura il limite di buffer del kernel.
-
-In questo caso tutto quello che il programma chiamante deve fare è di ripetere
-la lettura (o scrittura) per la quantità di byte rimanenti (lo stesso può
-avvenire scrivendo più di 4096 byte in una pipe, dato che quello è il limite
-di solito adottato per il buffer di trasmissione del kernel).
-
-\begin{figure}[htb]
-  \centering
-  \footnotesize
-  \begin{lstlisting}{}
-#include <unistd.h>
-
-ssize_t SockRead(int fd, void *buf, size_t count) 
-{
-    size_t nleft;
-    ssize_t nread;
-    nleft = count;
-    while (nleft > 0) {             /* repeat until no left */
-        if ( (nread = read(fd, buf, nleft)) < 0) {
-            if (errno == EINTR) {   /* if interrupted by system call */
-                continue;           /* repeat the loop */
-            } else {
-                return(nread);      /* otherwise exit */
-            }
-        } else if (nread == 0) {    /* EOF */
-            break;                  /* break loop here */ 
-        }
-        nleft -= nread;             /* set left to read */
-        buf +=nread;                /* set pointer */
-    }
-    return (count - nleft);
-}  
-  \end{lstlisting}
-  \caption{Funzione \func{SockRead}, legge \var{count} byte da un socket }
-  \label{fig:sock_SockRead_code}
-\end{figure}
-
-Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due
-funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un
-socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo
-avere letto o scritto esattamente il numero di byte specificato; il sorgente
-è riportato in \curfig\ e \nfig\ ed è disponibile fra i sorgenti allegati alla
-guida nei files \file{SockRead.c} e \file{SockWrite.c}.
+Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
+(una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
+per IPv6), che devono essere precedentemente allocate e passate attraverso il
+puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
+può essere nullo e deve essere allocato precedentemente.
 
 
-\begin{figure}[htb]
-  \centering
-  \footnotesize
-  \begin{lstlisting}{}
-#include <unistd.h>
-
-ssize_t SockWrite(int fd, const void *buf, size_t count) 
-{
-    size_t nleft;
-    ssize_t nwritten;
-
-    nleft = count;
-    while (nleft > 0) {             /* repeat until no left */
-        if ( (nwritten = write(fd, buf, nleft)) < 0) {
-            if (errno == EINTR) {   /* if interrupted by system call */
-                continue;           /* repeat the loop */
-            } else {
-                return(nwritten);   /* otherwise exit with error */
-            }
-        }
-        nleft -= nwritten;          /* set left to write */
-        buf +=nwritten;             /* set pointer */
-    }
-    return (count);
-}  
-  \end{lstlisting}
-  \caption{Funzione \func{SockWrite}, scrive \var{count} byte su un socket }
-  \label{fig:sock_SockWrite_code}
-\end{figure}
+Il formato usato per gli indirizzi in formato di presentazione è la notazione
+\textit{dotted decimal} per IPv4 e quello descritto in
+sez.~\ref{sec:IP_ipv6_notation} per IPv6.
 
 
-Come si può notare le funzioni ripetono la lettura/scrittura in un ciclo fino
-all'esaurimento del numero di byte richiesti, in caso di errore viene
-controllato se questo è \macro{EINTR} (cioè un'interruzione della system call
-dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
-l'errore viene ritornato interrompendo il ciclo.
+\index{socket!definizione|)}
 
 
-Nel caso della lettura, se il numero di byte letti è zero, significa che si è
-arrivati alla fine del file e pertanto si ritorna senza aver concluso la
-lettura di tutti i byte richiesti.
 
 
 
 
 
 
-\subsection{Un primo esempio di client}
-\label{sec:net_cli_sample}
 
 
-Lo scopo di questo esempio è fornire un primo approccio alla programmazione di
-rete e vedere come si usano le funzioni descritte in precedenza, alcune delle
-funzioni usate nell'esempio saranno trattate in dettaglio nel capitolo
-successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
-definizioni precise e dettagli di funzionamento che saranno trattati
-estensivamente più avanti.
 
 
-In \nfig\ è riportata la sezione principale del codice del nostro client
-elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richiesta.
 
 
-\begin{figure}[!htb]
-  \footnotesize
-  \begin{lstlisting}{}
-#include <sys/types.h>   /* predefined types */
-#include <unistd.h>      /* include unix standard library */
-#include <arpa/inet.h>   /* IP addresses conversion utilities */
-#include <sys/socket.h>  /* socket library */
-#include <stdio.h>       /* include standard I/O library */
-
-int main(int argc, char *argv[])
-{
-    int sock_fd;
-    int i, nread;
-    struct sockaddr_in serv_add;
-    char buffer[MAXLINE];
-     ...
-    /* create socket */
-    if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
-        perror("Socket creation error");
-        return -1;
-    }
-    /* initialize address */
-    memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
-    serv_add.sin_family = AF_INET;                   /* address type is INET */
-    serv_add.sin_port = htons(13);                   /* daytime post is 13 */
-    /* build address using inet_pton */
-    if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
-        perror("Address creation error");
-        return -1;
-    }
-    /* extablish connection */
-    if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
-        perror("Connection error");
-        return -1;
-    }
-    /* read daytime from server */
-    while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
-        buffer[nread]=0;
-        if (fputs(buffer, stdout) == EOF) {          /* write daytime */
-            perror("fputs error");
-            return -1;
-        }
-    }
-    /* error on read */
-    if (nread < 0) {
-        perror("Read error");
-        return -1;
-    }
-    /* normal exit */
-    return 0;
-}
-  \end{lstlisting}
-  \caption{Esempio di codice di un client elementare per il servizio daytime.}
-  \label{fig:net_cli_code}
-\end{figure}
-
-Il sorgente completo del programma (\file{ElemDaytimeTCPClient.c}, che
-comprende il trattamento delle opzioni e una funzione per stampare un
-messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
-può essere compilato su una qualunque macchina Linux.
-
-Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
-dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
-tutta la parte relativa al trattamento degli argomenti passati dalla linea di
-comando (effettuata con le apposite routine illustrate in
-\capref{sec:proc_opt_handling}).
-
-Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
-(\macro{AF\_INET}), di tipo TCP \macro{SOCK\_STREAM}. La funzione
-\macro{socket} ritorna il descrittore che viene usato per identificare il
-socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
-stampa un errore con la relativa routine e si esce.
-
-Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
-struttura \type{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
-il numero della porta del servizio. Il primo passo è inizializzare tutto a
-zero, per poi inserire il tipo di protocollo e la porta (usando per
-quest'ultima la funzione \func{htons} per convertire il formato dell'intero
-usato dal computer a quello usato nella rete), infine si utilizza la funzione
-\func{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di
-comando.
-
-Usando la funzione \func{connect} sul socket creato in precedenza
-(\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
-server specificato dall'indirizzo immesso nella struttura passata come secondo
-argomento, il terzo argomento è la dimensione di detta struttura. Dato che
-esistono diversi tipi di socket, si è dovuto effettuare un cast della
-struttura inizializzata in precedenza, che è specifica per i socket IPv4.  Un
-valore di ritorno negativo implica il fallimento della connessione.
-
-Completata con successo la connessione il passo successivo (\texttt{\small
-  34--40}) è leggere la data dal socket; il server invierà sempre una stringa
-di 26 caratteri della forma \verb|Wed Apr 4 00:53:00 2001\r\n|, che viene
-letta dalla funzione \func{read} e scritta su \file{stdout}.
-
-Dato il funzionamento di TCP la risposta potrà tornare in un unico pacchetto
-di 26 byte (come avverrà senz'altro nel caso in questione) ma potrebbe anche
-arrivare in 26 pacchetti di un byte.  Per questo nel caso generale non si può
-mai assumere che tutti i dati arrivino con una singola lettura, pertanto
-quest'ultima deve essere effettuata in un ciclo in cui si continui a leggere
-fintanto che la funzione \func{read} non ritorni uno zero (che significa che
-l'altro capo ha chiuso la connessione) o un numero minore di zero (che
-significa un errore nella connessione).
-
-Si noti come in questo caso la fine dei dati sia specificata dal server che
-chiude la connessione; questa è una delle tecniche possibili (è quella usata
-pure dal protocollo HTTP), ma ce ne possono essere altre, ad esempio FTP marca
-la conclusione di un blocco di dati con la sequenza ASCII \verb|\r\n|
-(carriage return e line feed), mentre il DNS mette la lunghezza in testa ad
-ogni blocco che trasmette. Il punto essenziale è che TCP non provvede nessuna
-indicazione che permetta di marcare dei blocchi di dati, per cui se questo è
-necessario deve provvedere il programma stesso.
-
-\subsection{Un primo esempio di server}
-\label{sec:net_serv_sample}
-
-Dopo aver illustrato il client daremo anche un esempio di un server
-elementare, in grado di rispondere al precedente client. Il listato è
-nuovamente mostrato in \nfig, il sorgente completo
-(\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
-directory \file{sources}.
-
-\begin{figure}[!htbp]
-  \footnotesize
-  \begin{lstlisting}{}
-#include <sys/types.h>   /* predefined types */
-#include <unistd.h>      /* include unix standard library */
-#include <arpa/inet.h>   /* IP addresses conversion utilities */
-#include <sys/socket.h>  /* socket library */
-#include <stdio.h>       /* include standard I/O library */
-#include <time.h>
-#define MAXLINE 80
-#define BACKLOG 10
-int main(int argc, char *argv[])
-{
-/* 
- * Variables definition  
- */
-    int list_fd, conn_fd;
-    int i;
-    struct sockaddr_in serv_add;
-    char buffer[MAXLINE];
-    time_t timeval;
-    ...
-    /* create socket */
-    if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
-        perror("Socket creation error");
-        exit(-1);
-    }
-    /* initialize address */
-    memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
-    serv_add.sin_family = AF_INET;                  /* address type is INET */
-    serv_add.sin_port = htons(13);                  /* daytime port is 13 */
-    serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
-    /* bind socket */
-    if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
-        perror("bind error");
-        exit(-1);
-    }
-    /* listen on socket */
-    if (listen(list_fd, BACKLOG) < 0 ) {
-        perror("listen error");
-        exit(-1);
-    }
-    /* write daytime to client */
-    while (1) {
-        if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
-            perror("accept error");
-            exit(-1);
-        }
-        timeval = time(NULL);
-        snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
-        if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
-            perror("write error");
-            exit(-1);
-        }
-        close(conn_fd);
-    }
-    /* normal exit */
-    exit(0);
-}
-  \end{lstlisting}
-  \caption{Esempio di codice di un semplice server per il servizio daytime.}
-  \label{fig:net_serv_code}
-\end{figure}
+% LocalWords:  socket sez cap BSD SVr XTI Transport Interface TCP stream UDP PF
+% LocalWords:  datagram broadcast descriptor sys int domain type protocol errno
+% LocalWords:  EPROTONOSUPPORT ENFILE kernel EMFILE EACCES EINVAL ENOBUFS raw
+% LocalWords:  ENOMEM table family AF address name glibc UNSPEC LOCAL Local IPv
+% LocalWords:  communication INET protocols ip AX Amateur IPX Novell APPLETALK
+% LocalWords:  Appletalk ddp NETROM NetROM Multiprotocol ATMPVC Access to ATM
+% LocalWords:  PVCs ITU ipv PLP DECnet Reserved for project NETBEUI LLC KEY key
+% LocalWords:  SECURITY Security callback NETLINK interface device netlink Low
+% LocalWords:  PACKET level packet ASH Ash ECONET Acorn Econet ATMSVC SVCs SNA
+% LocalWords:  IRDA PPPOX PPPoX WANPIPE Wanpipe BLUETOOTH Bluetooth POSIX bits
+% LocalWords:  dall'header tab SOCK capabilities capability styles DGRAM read
+% LocalWords:  SEQPACKET RDM sockaddr reference void fig Header uint socklen at
+% LocalWords:  addr netinet port len Stevens unsigned short casting nell'header
+% LocalWords:  BIND SERVICE bind union order big endian flowinfo dell'header ll
+% LocalWords:  multicast multicasting local socketpair sun path filesystem AARP
+% LocalWords:  pathname AppleTalk netatalk personal Apple ATPROTO atalk sat if
+% LocalWords:  ANYNET node ANYNODE ATADDR BCAST pcap IEEE linux ether ETH ALL
+% LocalWords:  sll ifindex ethernet halen MAC hatype ARP arp pkttype HOST recv
+% LocalWords:  OTHERHOST OUTGOING recvfrom recvmsg endianess little endtest Mac
+% LocalWords:  Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
+% LocalWords:  all'endianess htons ntohl ntohs long hostlong hostshort netlong
+% LocalWords:  sort netshort host inet aton ntoa dotted decimal const char src
+% LocalWords:  strptr struct dest addrptr INADDR NULL pton ntop presentation af
+% LocalWords:  numeric EAFNOSUPPORT size ENOSPC ENOAFSUPPORT ADDRSTRLEN ROUTE
+% LocalWords:  of tcpdump page
 
 
-Come per il client si includono gli header necessari a cui è aggiunto quello
-per trattare i tempi, e si definiscono alcune costanti e le variabili
-necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
-sono omesse le parti relative al trattamento delle opzioni da riga di comando.
-
-La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
-come pure l'inizializzazione della struttura \type{sockaddr\_in}, anche in
-questo caso si usa la porta standard del servizio daytime, ma come indirizzo
-IP si il valore predefinito \macro{INET\_ANY} che corrisponde ad un indirizzo
-generico (\texttt{\small 27--31}).
-
-Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
-\func{bind} che permette di associare la precedente struttura al socket, in
-modo che quest'ultimo possa essere usato per accettare connessioni su una
-qualunque delle interfacce di rete locali.
-
-Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
-socket, questo viene effettuato con la funzione \func{listen} che dice al
-kernel di accettare connessioni per il socket specificato, la funzione indica
-inoltre, con il secondo parametro, il numero massimo di connessioni che il
-kernel accetterà di mettere in coda per il suddetto socket.
-
-Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
-viene chiamato anche \textit{listening descriptor}) a questo punto il processo
-è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
-funzione \func{accept}, fin quando non arriva e viene accettata una
-connessione da un client.
-
-Quando questo avviene \func{accept} ritorna un secondo descrittore di socket,
-che viene chiamato \textit{connected descriptor} che è quello che viene usato
-dalla successiva chiamata alla \func{write} per scrivere la risposta al
-client, una volta che si è opportunamente (\texttt{\small 48--49}) costruita
-la stringa con la data da trasmettere. Completata la trasmissione il nuovo
-socket viene chiuso (\texttt{\small 54}).  Il tutto è inserito in un ciclo
-infinito (\texttt{\small 42--55}) in modo da poter ripetere l'invio della data
-ad una successiva connessione.
-
-È importante notare che questo server è estremamente elementare, infatti a
-parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
-un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
-scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
-come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
-attiva e il terminale da cui lo si è lanciato è stato sconnesso),
-occorrerebbero delle opportune modifiche.
 
 %%% Local Variables: 
 %%% mode: latex
 
 %%% Local Variables: 
 %%% mode: latex