X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=socket.tex;h=78be58c98d39c4761ca917cf490bfcf3f0fb56ca;hp=fa70b6d800a1094109394212b3c1d2ef866ad107;hb=d44259cffb0d41ed62ec80f7d653bd7606894866;hpb=9b0f636834e8d92e87131bbb99d7d846bab1421a

diff --git a/socket.tex b/socket.tex
index fa70b6d..78be58c 100644
--- a/socket.tex
+++ b/socket.tex
@@ -1,335 +1,445 @@
 %% socket.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2018 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 "Prefazione",
+%% 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}
+
+\chapter{I 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
-\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
-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}
+\section{Introduzione ai socket}
 \label{sec:sock_overview}
 
-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.
-\index{socket|(}
+In questa sezione daremo 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; ne illustreremo poi le caratteristiche e le differenti
+tipologie presenti ed infine tratteremo le modalità con cui possono essere
+creati.
 
+\index{socket!definizione|(}
 
-\subsection{I \textit{socket}}
+\subsection{Cosa sono 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 (vedi \secref{sec:ipc_pipes}) 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 la stessa
-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.
-
-
-\subsection{Concetti base}
-\label{sec:sock_gen}
+I \textit{socket} (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
+\textit{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à) ed oggi
+sono praticamente dimenticate.
+
+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.
 
 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
-problemi) siano diverse a seconda del tipo di protocollo di comunicazione
-usato, le funzioni da usare restano le stesse.
+dei protocolli di rete che su utilizzeranno (ed in particolare quelli del
+TCP/IP già illustrati in sez.~\ref{sec:net_tpcip}), 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 nella gestione dei socket 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
-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
-comunicazione considerano i dati come una sequenza continua di byte, altri
-invece li raggruppano in blocchi (i pacchetti).
-
-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
-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 ``\textsl{canali}'' dove
+affrontare cambiano radicalmente a seconda del tipo di comunicazione usato.
+La scelta di questo tipo di comunicazione (sovente anche detto \textsl{stile})
+va infatti ad incidere sulla semantica che verrà utilizzata a livello utente
+per gestire la comunicazione cioè su come inviare e ricevere i dati e sul
+comportamento effettivo delle funzioni utilizzate.
+
+La scelta di uno \textsl{stile} dipende sia dai meccanismi disponibili, sia
+dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni tipi di
+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 sempre inviati in blocchi separati e non
+divisibili.
+
+Un altro esempio delle differenze fra i diversi tipi di comunicazione concerne
+la possibilità che essa possa o meno perdere dati nella trasmissione, che
+possa o meno rispettare l'ordine in cui i dati inviati e ricevuti, o che possa
+accadere di inviare dei pacchetti di dati più volte (differenze che ad esempio
+sono presenti nel caso di utilizzo dei protocolli TCP o UDP).
+
+Un terzo esempio di differenza nel tipo di comunicazione concerne il modo in
+cui essa avviene nei confronti dei corrispondenti, 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 uno a molti come il \textit{broadcast} ed il \textit{multicast},
+in cui i pacchetti possono venire 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 diversi aspetti è associato ad un tipo di
+comunicazione che comporta una modalità diversa di gestire la stessa, ad
+esempio se la comunicazione è inaffidabile occorrerà essere in grado di
+gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
+dovranno essere opportunamente trattati, se è uno a molti occorrerà tener
+conto della eventuale unidirezionalità della stessa, ecc.
+
+\index{socket!definizione|)}
 
 
-\section{La creazione di un \textit{socket}}
+\subsection{La creazione di un socket}
 \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;
-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
-\funcd{socket}; questa restituisce un \textit{file descriptor}\footnote{del
-  tutto analogo a quelli che si ottengono per i file di dati e le pipe,
-  descritti in \secref{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.
-  
-  \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:
+La creazione di un socket avviene attraverso l'uso della funzione di sistema 
+\funcd{socket}; essa restituisce un \textit{file descriptor} (del tutto
+analogo a quelli che si ottengono per i file di dati e le \textit{pipe},
+descritti in sez.~\ref{sec:file_fd}) che serve come riferimento al socket; il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fdecl{int socket(int domain, int type, int protocol)}
+\fdesc{Apre un socket.} 
+}
+
+{La funzione ritorna un valore positivo in caso di successo e $-1$ per un
+  errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \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.
-  \item[\errcode{EMFILE}] Si è ecceduta la tabella dei file.
-  \item[\errcode{EACCES}] Non si hanno privilegi per creare un socket nel
+  \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
     dominio o con il protocollo specificato.
-  \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}}
-\end{prototype}
+  \item[\errcode{EAFNOSUPPORT}] famiglia di indirizzi non supportata.
+  \item[\errcode{EINVAL}] argomento \param{type} invalido.
+  \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
+  \item[\errcode{ENFILE}] si è raggiunto il limite massimo di file aperti.
+  \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
+    (può essere anche \errval{ENOMEM}).
+  \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
+    non sono supportati nel dominio.
+  \end{errlist}
+  ed inoltre a seconda del protocollo usato, potranno essere generati altri
+  errori, che sono riportati nelle pagine di manuale relative al protocollo.}
+\end{funcproto}
+
 
 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
-(definisce cioè la famiglia di protocolli, come vedremo in
-\secref{sec:sock_domain}), \param{type} specifica il tipo di socket (definisce
-cioè lo stile di comunicazione, come vedremo in \secref{sec:sock_type}) e
-\param{protocol} 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}).
+(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}).
+
+% TODO: l'ultimo argomento viene usato anche dai nuovi ping socket introdotti
+% con il kernel 3.0, vedi anche http://lwn.net/Articles/420799/ e
+% http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c319b4d76b9e583a5d88d6bf190e079c4e43213d 
 
 Si noti che la creazione del socket si limita ad allocare le opportune
 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
 non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
-attraverso i quali si vuole effettuare la comunicazione.
+attraverso i quali si vuole effettuare la comunicazione. Questo significa che
+la funzione da sola non è in grado di fornire alcun tipo di 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
-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 pagine di manuale di Linux si riferiscono
-a questi anche come \textit{name space}, (nome che però il manuale delle
-\acr{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 \tabref{tab:net_pf_names}.
+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}, (nome che invece il manuale della \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]
+\begin{table}[!htb]
   \footnotesize
   \centering
-  \begin{tabular}[c]{|l|l|l|}
+  \begin{tabular}[c]{|l|l|l|l|}
        \hline
-       \textbf{Nome}      & \textbf{Utilizzo}           &\textbf{Man page} \\
+       \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
        \hline
        \hline
-       \const{PF\_UNIX},
-       \const{PF\_LOCAL}  & Local communication            & unix(7)    \\
-       \const{PF\_INET}   & IPv4 Internet protocols        & ip(7)      \\
-       \const{PF\_INET6}  & IPv6 Internet protocols        & ipv6(7)    \\
-       \const{PF\_IPX}    & IPX - Novell protocols         &            \\
-       \const{PF\_NETLINK}& Kernel user interface device   & netlink(7) \\
-       \const{PF\_X25}    & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\
-       \const{PF\_AX25}   & Amateur radio AX.25 protocol   &            \\
-       \const{PF\_ATMPVC} & Access to raw ATM PVCs         &            \\
-       \const{PF\_APPLETALK}& Appletalk                    & ddp(7)     \\
-       \const{PF\_PACKET} & Low level packet interface     & packet(7)  \\    
+       \constd{AF\_UNSPEC}   & 0& Non specificato               &            \\
+       \constd{AF\_LOCAL}    & 1& Local communication           & unix(7)    \\
+       \constd{AF\_UNIX}, \constd{AF\_FILE}&1&Sinonimi di \const{AF\_LOCAL}& \\
+       \constd{AF\_INET}     & 2& IPv4 Internet protocols       & ip(7)      \\
+       \constd{AF\_AX25}     & 3& Amateur radio AX.25 protocol  &            \\
+       \constd{AF\_IPX}      & 4& IPX - Novell protocols        &            \\
+       \constd{AF\_APPLETALK}& 5& Appletalk                     & ddp(7)     \\
+       \constd{AF\_NETROM}   & 6& Amateur radio NetROM          &            \\
+       \constd{AF\_BRIDGE}   & 7& Multiprotocol bridge          &            \\
+       \constd{AF\_ATMPVC}   & 8& Access to raw ATM PVCs        &            \\
+       \constd{AF\_X25}      & 9& ITU-T X.25 / ISO-8208 protocol& x25(7)     \\
+       \constd{AF\_INET6}    &10& IPv6 Internet protocols       & ipv6(7)    \\
+       \constd{AF\_ROSE}     &11& Amateur Radio X.25 PLP        &            \\
+       \constd{AF\_DECnet}   &12& Reserved for DECnet project   &            \\
+       \constd{AF\_NETBEUI}  &13& Reserved for 802.2LLC project &            \\
+       \constd{AF\_SECURITY} &14& Security callback pseudo AF   &            \\
+       \constd{AF\_KEY}      &15& AF\_KEY key management API    &            \\
+       \constd{AF\_NETLINK}  &16& Kernel user interface device  & netlink(7) \\
+       \constd{AF\_ROUTE}    &16& Sinonimo di \const{AF\_NETLINK} emula BSD.&\\
+       \constd{AF\_PACKET}   &17& Low level packet interface    & packet(7)  \\
+       \constd{AF\_ASH}      &18& Ash                           &    \\
+       \constd{AF\_ECONET}   &19& Acorn Econet                  &    \\
+       \constd{AF\_ATMSVC}   &20& ATM SVCs                      &    \\
+       \constd{AF\_RDS}      &21& RDS Sockets                   &    \\
+       \constd{AF\_SNA}      &22& Linux SNA Project             &    \\
+       \constd{AF\_IRDA}     &23& IRDA socket (infrarossi)      & irda(7)    \\
+       \constd{AF\_PPPOX}    &24& PPPoX socket                  &    \\
+       \constd{AF\_WANPIPE}  &25& Wanpipe API socket            &    \\
+       \constd{AF\_LLC}      &26& Linux LLC                     &    \\
+       \constd{AF\_IB}       &27&  Native InfiniBand address    &    \\
+       \constd{AF\_MPLS}     &28& MPSL                          &    \\
+       \constd{AF\_CAN}      &29& Controller Are Network        &    \\
+       \constd{AF\_TIPC}     &30& TIPC sockets                  &    \\
+       \constd{AF\_BLUETOOTH}&31& Bluetooth socket              &    \\
+       \constd{AF\_IUCV}     &32& IUCV sockets                  &    \\
+       \constd{AF\_RXRPC}    &33& RxRPC sockets                 &    \\
+       \constd{AF\_ISDN}     &34& mISDN sockets                 &    \\
+       \constd{AF\_PHONET}   &35& Phonet sockets                &    \\
+       \constd{AF\_IEEE802154}&36& IEEE802154 sockets           &    \\
+       \constd{AF\_CAIF}     &37& CAIF sockets                  &    \\
+       \constd{AF\_ALG}      &38& Algorithm sockets             &    \\
+       \constd{AF\_NFC}      &39& NFC sockets                   &    \\
+       \constd{AF\_VSOCK}    &40& vSockets                      &    \\
+       \constd{AF\_KCM}      &41& Kernel Connection Multiplexor &    \\
+       \constd{AF\_QIPCRTR}  &42& Qualcomm IPC Router           &    \\
+       \constd{AF\_SMC}      &43& smc sockets                   &    \\
        \hline
   \end{tabular}
-  \caption{Famiglie di protocolli definiti in Linux}
+  \caption{Famiglie di protocolli definiti in Linux.} 
   \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 \const{SOCK\_RAW} possono essere
-creati solo da processi che hanno i privilegi di root (cioè con user-ID
-effettivo uguale a zero) o con la capability \texttt{CAP\_NET\_RAW}.
-
-
-\subsection{Il tipo, o stile}
+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.} Qui si sono indicati i nomi con il prefisso \texttt{AF\_}
+seguendo la convenzione usata nelle pagine di manuale.
+
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+indirizzi, sono definiti dall'\textit{header file} \headfiled{socket.h}. Un
+elenco, aggiornato alla versione 4.15, delle famiglie di protocolli
+disponibili in Linux è riportato in tab.~\ref{tab:net_pf_names}.  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 \constd{AF\_MAX} che
+indica il valore massimo associabile ad un dominio.
+
+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 \ids{UID} effettivo uguale a zero) o dotati della
+\textit{capability} \const{CAP\_NET\_RAW}.
+
+
+\subsection{Il tipo di socket}
 \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
-\acr{glibc} mettono a disposizione i seguenti tipi di socket (che il manuale
-della \acr{glibc} chiama \textit{styles}) definiti come \ctyp{int} in
-\file{socket.h}:
-
-\begin{list}{}{}
-\item \const{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{GlibcMan} 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.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{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
-  byte (da cui il nome \textit{stream}). 
-\item \const{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 \const{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 \textit{out-of-band}, vedi sez.~\ref{sec:TCP_urgent_data}).
+\item[\constd{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[\constd{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
   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 \const{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[\constd{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
   rete e alle varie interfacce. I normali programmi di comunicazione non
-  devono usarlo.
-\item \const{SOCK\_RDM} Provvede un canale di trasmissione di pacchetti
-  affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
-\item \const{SOCK\_PACKET} Obsoleto, non deve essere usato.
-\end{list}
-
-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.
+  devono usarlo, è riservato all'uso di sistema.
+\item[\constd{SOCK\_RDM}] Provvede un canale di trasmissione di dati
+  affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
+\item[\constd{SOCK\_PACKET}] Obsoleto, non deve essere più usato (e pertanto
+  non ne parleremo ulteriormente).
+\end{basedescript}
+
+A partire dal kernel 2.6.27 l'argomento \param{type} della funzione
+\func{socket} assume un significato ulteriore perché può essere utlizzato per
+impostare dei flag relativi alle caratteristiche generali del \textit{socket}
+non strettamente attinenti all'indicazione del tipo secondo i valori appena
+illustrati. Essi infatti possono essere combinati con un OR aritmetico delle
+ulteriori costanti:
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{SOCK\_CLOEXEC}] imposta il flag di \textit{close-on-exec} sul
+  file descriptor del socket, ottenendo lo stesso effetto del flag
+  \const{O\_CLOEXEC} di \func{open} (vedi tab.~\ref{tab:open_operation_flag}),
+  di cui costituisce l'analogo.
+
+\item[\constd{SOCK\_NONBLOCK}] crea il socket in modalità non-bloccante, con
+  effetti identici ad una successiva chiamata a \func{fcntl} per impostare il
+  flag di \const{O\_NONBLOCK} sul file descriptor (si faccia di nuovo
+  riferimenti al significato di quest'ultimo come spiegato in
+  tab.~\ref{tab:open_operation_flag}).
+\end{basedescript}
+
+Si tenga presente inoltre 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{tabular}{l|c|c|c|c|c|}
-   \multicolumn{1}{c}{} &\multicolumn{1}{c}{\const{SOCK\_STREAM}}& 
-     \multicolumn{1}{c}{\const{SOCK\_DGRAM}} & 
-     \multicolumn{1}{c}{\const{SOCK\_RAW}} & 
-     \multicolumn{1}{c}{\const{SOCK\_PACKET}}& 
-     \multicolumn{1}{c}{\const{SOCK\_SEQPACKET}} \\
-     \cline{2-6}
-    \const{PF\_UNIX}      &  si & si  &      &     &     \\
-     \cline{2-6}
-    \const{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
-     \cline{2-6}
-    \const{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
-     \cline{2-6}
-    \const{PF\_IPX}       &     &     &      &     &     \\
-     \cline{2-6}
-    \const{PF\_NETLINK}   &     &  si &  si  &     &     \\
-     \cline{2-6}
-    \const{PF\_X25}       &     &     &      &     &  si \\
-     \cline{2-6}
-    \const{PF\_AX25}      &     &     &      &     &     \\
-     \cline{2-6}
-    \const{PF\_ATMPVC}    &     &     &      &     &     \\
-     \cline{2-6}
-    \const{PF\_APPLETALK} &     & si  &  si  &     &     \\
-     \cline{2-6}
-    \const{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{AF\_UNIX}     &  si & si  &  --  & -- &  si\footnotemark \\
+     \hline
+    \const{AF\_LOCAL}&\multicolumn{5}{|c|}{sinonimo di \const{AF\_UNIX}}\\
+     \hline
+    \const{AF\_INET}      & TCP & UDP & IPv4 & --  & --  \\
+     \hline
+    \const{AF\_INET6}     & TCP & UDP & IPv6 & --  & -- \\
+     \hline
+    \const{AF\_IPX}       & --  & si  &  --  & --  & -- \\
+     \hline
+    \const{AF\_NETLINK}   & --  & si  &  si  & --  & -- \\
+     \hline
+    \const{AF\_X25}       & --  & --  &  --  & --  & si \\
+     \hline
+    \const{AF\_AX25}      & --  & si  &  si  & --  & si \\
+     \hline
+%    \const{AF\_ATMPVC}    & --  & --  &  --  & --  & -- \\
+%     \hline
+    \const{AF\_APPLETALK} & --  & si  &  si  & --  & -- \\
+     \hline
+    \const{AF\_PACKET}    & --  & si  &  si  & --  & -- \\
+     \hline
+    \const{AF\_KEY}       & --  & --  &  si  & --  & -- \\
+     \hline
+    \const{AF\_IRDA}      & si  & si  &  si  & --  & si \\
+     \hline
+    \const{AF\_NETROM}    & --  & --  &  --  & --  & si \\
+     \hline
+    \const{AF\_ROSE}      & --  & --  &  --  & --  & si \\
+     \hline
+    \const{AF\_RDS}       & --  & --  &  --  & --  & si \\
+     \hline
+    \const{AF\_ECONET}    & --  & 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}
 
-In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
-valide possibili per le varie 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.
+\footnotetext{supportati a partire dal kernel 2.6.4 per socket che conservano
+  i limiti dei messaggi e li consegnano in sequenza ordinata.}
 
+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 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}
 
-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.
 
-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
-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
-questi puntatori, il C ANSI risolve questo problema coi i puntatori generici
-(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla definizione
-dello standard ANSI, e per questo nel 1982 fu scelto di definire una struttura
-generica per gli indirizzi dei socket, \struct{sockaddr}, che si è riportata in
-\figref{fig:sock_sa_gen_struct}.
+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]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
-    \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}
+  \begin{minipage}[c]{0.80\textwidth}
+    \includestruct{listati/sockaddr.h}
   \end{minipage} 
   \caption{La struttura generica degli indirizzi dei socket
     \structd{sockaddr}.} 
@@ -339,12 +449,12 @@ struct sockaddr {
 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
-POSIX.1g, riassunti in \tabref{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}.
+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 \headfile{sys/socket.h}.
 
 \begin{table}[!htb]
   \centering
@@ -356,21 +466,21 @@ include in cui sono definiti; la struttura 
     \multicolumn{1}{|c|}{\textbf{Header}} \\
     \hline
     \hline
-    \type{int8\_t}   & intero a 8 bit con segno   & \file{sys/types.h}\\
-    \type{uint8\_t}  & intero a 8 bit senza segno & \file{sys/types.h}\\
-    \type{int16\_t}  & intero a 16 bit con segno  & \file{sys/types.h}\\
-    \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
-    \type{int32\_t}  & intero a 32 bit con segno  & \file{sys/types.h}\\
-    \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
+    \typed{int8\_t}   & intero a 8 bit con segno   & \headfile{sys/types.h}\\
+    \typed{uint8\_t}  & intero a 8 bit senza segno & \headfile{sys/types.h}\\
+    \typed{int16\_t}  & intero a 16 bit con segno  & \headfile{sys/types.h}\\
+    \typed{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\
+    \typed{int32\_t}  & intero a 32 bit con segno  & \headfile{sys/types.h}\\
+    \typed{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\
     \hline
-    \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
-    \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
-    un socket& \file{sys/socket.h}\\
+    \typed{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\
+    \typed{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
+    un socket& \headfile{sys/socket.h}\\
     \hline
-    \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}\\
+    \typed{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & 
+    \headfile{netinet/in.h}\\
+    \typed{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& 
+    \headfile{netinet/in.h}\\
     \hline
   \end{tabular}
   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 
@@ -378,176 +488,371 @@ include in cui sono definiti; la struttura 
   \label{tab:sock_data_types}
 \end{table}
 
-In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
-aggiuntivo \code{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 \ctyp{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
-\var{sa\_family} 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.
+\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.
+
+Se si usa una struttura \struct{sockaddr} per allocare delle variabili
+generiche da usare in seguito per degli indirizzi si pone il problema che
+niente assicura che i dati necessari per le varie famiglie di indirizzi
+possano rientrare nella dimensione del campo \var{sa\_data} indicata in
+fig.~\ref{fig:sock_sa_gen_struct}, anzi, come vedremo in
+sez.~\ref{sec:sock_sa_ipv6}, nel caso di indirizzi IPv6 questa non è proprio
+sufficiente. 
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{0.95\textwidth}
+    \includestruct{listati/sockaddr_storage.h}
+  \end{minipage} 
+  \caption{La struttura generica degli indirizzi dei socket
+    \structd{sockaddr\_storage}.} 
+  \label{fig:sock_sa_storage_struct}
+\end{figure}
+
+Per questo l'interfaccia di programmazione dei socket prevede la defizione di
+una speciale struttura \struct{sockaddr\_storage} illustrata in
+fig.~\ref{fig:sock_sa_storage_struct}, in cui di nuovo si usa il primo campo
+(\var{ss\_family}) per indicare il tipo di indirizzo, ed in cui i campi
+successivi sono utilizzati per allineare i dati al tipo di architettura
+hardware utilizzata, e per allocare uno spazio sufficiente ampio per contenere
+qualunque tipo di indirizzo supportato. Allocando questa struttura si ha la
+certezza di non eccedere le dimensioni qualunque sia il tipo di indirizzi che
+si useranno, pertanto risulta utile tutte le volte che si devono gestire in
+maniera generica tipi di indirizzi diversi (ad esempio IPv4 ed IPv6).
 
 
 \subsection{La struttura degli indirizzi IPv4}
 \label{sec:sock_sa_ipv4}
 
-I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
-attraverso internet; la struttura per gli indirizzi per un socket internet
-(IPv4) è definita come \struct{sockaddr\_in} nell'header file
-\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in
-\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
+I socket di tipo \const{AF\_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
+\headfiled{netinet/in.h} ed ha la forma mostrata in
+fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
 \begin{figure}[!htb]
   \footnotesize\centering
-  \begin{minipage}[c]{15cm}
-    \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}
+  \begin{minipage}[c]{0.80\textwidth}
+    \includestruct{listati/sockaddr_in.h}
   \end{minipage} 
-  \caption{La struttura degli indirizzi dei socket internet (IPv4)
-    \structd{sockaddr\_in}.}
+  \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
-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 impostato al numero di protocollo.
-
-Il membro \var{sin\_family} deve essere sempre impostato; \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 (con user-ID
-effettivo uguale a zero) o con la capability \texttt{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 \direct{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è
-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
-problema e le relative soluzioni).
+L'indirizzo di un socket Internet (secondo IPv4) comprende l'indirizzo
+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 di per sé non prevede numeri di porta, questi sono utilizzati
+solo dai protocolli di livello superiore come TCP e UDP, ma devono essere
+indicati qui. Inoltre questa struttura viene usata anche per i socket RAW che
+accedono direttamente al livello di IP, in questo caso il numero della porta
+deve essere impostato al numero di protocollo.
+
+Il membro \var{sin\_family} deve essere sempre impostato a \constd{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 \ids{UID} effettivo
+uguale a zero) o con la \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 \dirct{union} usata per accedere alle diverse classi di indirizzi) che
+direttamente come intero. In \headfile{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} (vedi
+sez.~\ref{sec:endianness}), questo comporta la 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}
 
-Essendo IPv6 un'estensione di IPv4 i socket di tipo \const{PF\_INET6} sono
+Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{AF\_INET6} sono
 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 \headfile{netinet/in.h}, è
+riportata in fig.~\ref{fig:sock_sa_ipv6_struct}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
-    \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}
+  \begin{minipage}[c]{0.80\textwidth}
+    \includestruct{listati/sockaddr_in6.h}
   \end{minipage} 
-  \caption{La struttura degli indirizzi dei socket IPv6 
-    \structd{sockaddr\_in6}.}
+  \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}
 
-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 \secref{sec:IP_ipv6head}) ed il loro uso è sperimentale.
+Il campo \var{sin6\_family} deve essere sempre impostato ad \constd{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,
-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 \struct{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; anche in questo caso esistono alcuni valori
+predediniti, ma essendo il campo un vettore di byte non è possibile assegnarli
+con il calore di una costante. Esistono però le variabili predefinite
+\var{in6addr\_any} (che indica l'indirizzo generico) e \var{in6addr\_loopback}
+(che indica l'indirizzo di loopback) il cui valore può essere copiato in
+questo campo. A queste due variabili si aggiungono le macro
+\macrod{IN6ADDR\_ANY\_INIT} e \macrod{IN6ADDR\_LOOPBACK\_INIT} per effettuare
+delle assegnazioni statiche.
+
+Infine il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il
+kernel 2.4, per gestire alcune operazioni riguardanti il
+\textit{multicasting}, è supportato solo per gli indirizzi di tipo
+\textit{link-local} (vedi sez.~\ref{sec:IP_ipv6_unicast}) e deve contenere
+l'\textit{interface index} (vedi sez.~\ref{sec:sock_ioctl_netdevice}) della
+scheda di rete.  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 (per questo se necessario è opportuno usare
+\struct{sockaddr\_storage}).
 
 
 \subsection{La struttura degli indirizzi locali}
 \label{sec:sock_sa_local}
 
-I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
-comunicazione fra processi che stanno sulla stessa macchina (per vengono
-chiamati \textit{local domain} o anche \textit{Unix domain}); essi rispetto ai
-precedenti possono essere anche creati in maniera anonima attraverso la
-funzione \func{socketpair} (vedi \secref{sec:ipc_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{AF\_UNIX} o \const{AF\_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]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
-    \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}
+  \begin{minipage}[c]{0.80\textwidth}
+    \includestruct{listati/sockaddr_un.h}
   \end{minipage} 
-  \caption{La struttura degli indirizzi dei socket locali 
-    \structd{sockaddr\_un}.}
+  \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
+    locali (detti anche \textit{unix domain}) definita in
+    \headfiled{sys/un.h}.}
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
-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 un file (di tipo socket) nel filesystem o una stringa univoca
-(tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
-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).
+In questo caso il campo \var{sun\_family} deve essere \constd{AF\_UNIX},
+mentre il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due
+forme; può essere ``\textit{named}'' ed in tal caso deve corrispondere ad un
+file (di tipo socket) presente nel filesystem o essere ``\textit{abstract}''
+nel qual caso viene identificato da una stringa univoca in uno spazio di nomi
+astratto. 
+
+Nel primo caso l'indirizzo viene specificato in \var{sun\_path} come una
+stringa (terminata da uno zero) corrispondente al \textit{pathname} del file;
+nel secondo caso (che è specifico di Linux e non portabile) \var{sun\_path}
+deve iniziare con uno zero ed il nome verrà costituito dai restanti byte che
+verranno interpretati come stringa senza terminazione (un byte nullo non ha in
+questo caso nessun significato).
+
+In realtà esiste una terza forma, \textit{unnamed}, che non è possibile
+indicare in fase di scrittura, ma che è quella che viene usata quando si legge
+l'indirizzo di un socket anonimo creato con \texttt{socketpair}; in tal caso
+la struttura restituita è di dimensione \code{sizeof(sa\_family\_t)}, quindi
+\var{sun\_path} non esiste e non deve essere referenziato.
+
+\subsection{La struttura degli indirizzi AppleTalk}
+\label{sec:sock_sa_appletalk}
+
+I socket di tipo \const{AF\_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} è \constd{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 \headfiled{netatalk/at.h}.
 
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{0.80\textwidth}
+    \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 \constd{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 \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:endianness}); esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+valore \constd{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 \constd{AT\_ANYNODE} che indica anche il nodo
+corrente, ed il valore \constd{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{AF\_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 \textit{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 \url{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 \constd{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 (\ids{UID} effettivo nullo) o
+con la \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} (vedi sez.~\ref{sec:TCP_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]{\textwidth}
+    \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}
+
+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 dati relativi a ciascun
+pacchetto.
+
+Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
+\constd{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 (l'\textit{inxterface index} (vedi
+sez.~\ref{sec:sock_ioctl_netdevice}) 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: \constd{PACKET\_HOST} per un pacchetto indirizzato alla
+macchina ricevente, \constd{PACKET\_BROADCAST} per un pacchetto di
+\textit{broadcast}, \constd{PACKET\_MULTICAST} per un pacchetto inviato ad un
+indirizzo fisico di \textit{multicast}, \constd{PACKET\_OTHERHOST} per un
+pacchetto inviato ad un'altra stazione (e ricevuto su un'interfaccia in modo
+promiscuo), \constd{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{AF\_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 
 
-% 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
 
+% TODO aggiungere AF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25 ?
 
-% 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
 
 
 
@@ -555,83 +860,48 @@ 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
-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}\index{endianess}}
-\label{sec:sock_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
-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}.
-
-La \textit{endianess}\index{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 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
-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.
+indirizzi, limitandoci però agli indirizzi Internet.  Come accennato gli
+indirizzi e i numeri di porta usati nella rete devono essere forniti nel
+cosiddetto \textit{network order}, che corrisponde al formato \textit{big
+  endian} (vedi sez.~\ref{sec:endianness}), anche quando la proprio macchina
+non usa questo formato, cosa che può comportare la necessità di eseguire delle
+conversioni.
+
 
 \subsection{Le funzioni per il riordinamento}
 \label{sec:sock_func_ord}
 
-Il problema connesso all'endianess\index{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.
+Come già visto in sez.~\ref{sec:endianness} il problema connesso
+all'\textit{endianness} è 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{ntonl} e \funcd{ntons} ed i
+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.
- 
-  \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.
-
-  \funcdecl{unsigned long int ntonl(unsigned long int netlong)}
-  Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
-  della macchina.
-
-  \funcdecl{unsigned sort int ntons(unsigned short int netshort)}
-  Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
-  della macchina.
-  
-  \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non hanno
-    errori.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{unsigned long int htonl(unsigned long int hostlong)}
+\fdesc{Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
+  quello della rete.} 
+\fdecl{unsigned short int htons(unsigned short int hostshort)}
+\fdesc{Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
+  quello della rete.}
+\fdecl{unsigned long int ntohl(unsigned long int netlong)}
+\fdesc{Converte l'intero a 32 bit \param{netlong} dal formato della rete a
+  quello della macchina.}
+\fdecl{unsigned sort int ntohs(unsigned short int netshort)}
+\fdesc{Converte l'intero a 16 bit \param{netshort} dal formato della rete a
+  quello della macchina.}
+}
+
+{Tutte le funzioni restituiscono il valore convertito, e non prevedono
+  errori.}
+\end{funcproto}
 
 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
@@ -644,502 +914,219 @@ 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 
-  \func{inet\_ntoa}}
+\subsection{Le funzioni di conversione per gli indirizzi IPv4}
 \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 simbolica
-dei numeri IP che si usa normalmente.
+Un secondo insieme di funzioni di manipolazione è quello che serve per passare
+dalla rappresentazione simbolica degli indirizzi IP al formato binario
+previsto dalla struttura degli indirizzi di
+fig.~\ref{fig:sock_sa_ipv4_struct}, e viceversa. La notazione più comune è la
+cosiddetta notazione \itindex{dotted-decimal} \textit{dotted-decimal}, che
+prevede che gli indirizzi IPv4 siano indicati con l'espressione del valore
+numerico decimale di ciascuno dei 4 byte che li costituiscono separati da un
+punto (ad esempio \texttt{192.168.0.1}).
+
+In realtà le funzioni che illustreremo supportano una notazione che più
+propriamente dovrebbe esser chiamata \textit{numbers-and-dot} in quanto il
+valore può essere indicato con numeri espressi sia in decimale, che in ottale
+(se indicati apponendo uno zero) che in esadecimale (se indicati apponendo
+\texttt{0x}). Inoltre per la parte meno significativa dell'espressione, quella
+che riguarda l'indirizzo locale, si può usare, eliminando altrettanti punti,
+valori a 16 o a 24 bit, e togliendo tutti i punti, si può usare anche
+direttamente un valore numerico a 32 bit.\footnote{la funzionalità si trova
+  anche in gran parte dei programmi che usano indirizzi di rete, e deriva
+  direttamente da queste funzioni.}
+
+Tradizionalmente la conversione di un indirizzo \textit{dotted-decimal} al
+valore numerico veniva eseguita dalla funzione \funcd{inet\_addr} (prevista
+fin dalle origini in BSD e inclusa in POSIX.1-2001) il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{in\_addr\_t inet\_addr(const char *strptr)}
+\fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in nel
+  numero IP in network order.} 
+}
+
+{La funzione ritorna il valore dell'indirizzo in caso di successo e
+  \const{INADDR\_NONE} per un errore e non genera codici di errore.}
+\end{funcproto}
+
+La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
+\textit{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 dato che genererebe comunque
+un errore; per questo motivo essa è generalmente deprecata in favore di
+\func{inet\_aton}.
+
+Per effettuare la conversione inversa la funzione usata tradizionalmente è
+\funcd{inet\_ntoa}, anch'essa presente fin da BSD 4.3, in cui si riprende la
+notazione già vista in sez.~\ref{sec:sock_func_ord} che usa la lettera
+\texttt{n} come mnemonico per indicare la rete ed \texttt{a} (per ASCII) come
+mnemonico per indicare la stringa corrispodente all'indirizzo; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{char *inet\_ntoa(struct in\_addr addrptr)}
+\fdesc{Converte un indirizzo IP in una stringa \textit{dotted decimal}.} 
+}
+
+{La funzione l'indirizzo della stringa con il valore dell'indirizzo convertito
+  e non prevede errori.}
+\end{funcproto}
+
+La funzione converte il valore a 32 bit dell'indirizzo, espresso in
+\textit{network order}, e preso direttamente con un puntatore al relativo
+campo della struttura degli indirizzi, restituendo il puntatore alla stringa
+che contiene l'espressione in formato \textit{dotted-decimal}. Si deve tenere
+presente che la stringa risiede in un segmento di memoria statica, per cui
+viene riscritta ad ogni chiamata e la funzione non è rientrante.
+
+Per rimediare ai problemi di \funcd{inet\_addr} è stata sostituita da
+\funcd{inet\_aton}, che però non è stata standardizzata e non è presente in
+POSIX.1-2001, anche se è definita sulla gran parte dei sistemi Unix; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{int inet\_aton(const char *src, struct in\_addr *dest)}
+\fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in un
+  indirizzo IP.}
+}
 
-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
-  order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
-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.
+{La funzione ritorna un valore non nullo in caso di successo e $0$ per un
+  errore e non genera codici di errore.}
+\end{funcproto}
 
-  \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
-  la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
+La funzione 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 un valore diverso da zero se l'indirizzo è
+valido e la conversione ha successo e 0 in caso contrario. Se usata
+con \param{dest} inizializzato a \val{NULL} può essere usata per effettuare la
+validazione dell'indirizzo espresso da \param{src}.
 
-  \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
-  Converte un indirizzo IP in una stringa \textit{dotted decimal}.
+Oltre a queste tre funzioni esistono le ulteriori \funcm{inet\_lnaof},
+\funcm{inet\_netof} e \funcm{inet\_makeaddr} che assumono la ormai obsoleta e
+deprecata suddivisione in classi degli indirizzi IP per fornire la parte di
+rete e quella di indirizzo locale. Ad oggi il loro uso non ha più alcun senso
+per ciò non le tratteremo.
 
-  \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 \secref{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 è rientrante.
-
-
-\subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
+\subsection{Le funzioni di conversione per indirizzi IP generici}
 \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}.
 
-% \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
-indirizzo e può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La prima
-funzione è \funcd{inet\_pton}, che serve a convertire una stringa in un
-indirizzo, il suo prototipo è:
-\begin{prototype}{sys/socket.h}
-{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}
+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{funcproto}{
+\fhead{sys/socket.h}
+\fdecl{int inet\_pton(int af, const char *src, void *addr\_ptr)} 
+\fdesc{Converte l'indirizzo espresso tramite una stringa nel valore numerico.} 
+}
+
+{La funzione ritorna $1$ in caso di successo, $0$ se \param{src} non contiene
+  una rappresentazione valida per la famiglia di indirizzi indicati
+  da \param{af} e $-1$ se \param{af} specifica una famiglia di indirizzi non
+  valida, e solo in quest'ultimo caso  \var{errno} assumerà il valore
+  \errcode{EAFNOSUPPORT}.
+}
+\end{funcproto}
 
 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, e zero se la stringa non rappresenta
-un indirizzo valido, e negativo se \param{af} specifica una famiglia di
-indirizzi non valida.
-
-La seconda funzione è \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)}
-  Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
- 
-  \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}
+memorizzato all'indirizzo puntato da \param{addr\_ptr}. La funzione supporta
+per IPv4 la sola notazione \textit{dotted-decimal}, e non quella più completa
+\textit{number-and-dot} che abbiamo visto per \func{inet\_aton}. Per IPv6 la
+notazione prevede la suddivisione dei 128 bit dell'indirizzo in 16 parti di 16
+bit espresse con valori esadecimali separati dal carattere ``\texttt{:}'' ed
+una serie di valori nulli possono essere sostituiti (una sola volta, sempre a
+partire dalla sinistra) con la notazione ``\texttt{::}'', un esempio di
+indirizzo in questa forma potrebbe essere \texttt{2001:db8::8:ba98:2078:e3e3},
+per una descrizione più completa si veda sez.~\ref{sec:IP_ipv6_notation}.
+
+La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
+indirizzo in una stringa; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fdecl{char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
+\fdesc{Converte l'indirizzo dalla relativa struttura in una stringa simbolica.} 
+}
+
+{La funzione ritorna un puntatore non nullo alla stringa convertita in caso di
+  successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
+  dei 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 è
+    \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
       una valida.
-  \end{errlist}}
-\end{prototype}
+  \end{errlist}
+}
+\end{funcproto}
+
 
 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}.
+essere almeno \constd{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
+\constd{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
+comunque essere specificata con il parametro \param{len}.
 
 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.
-
-Il formato usato per gli indirizzi in formato di presentazione è la notazione
-\textit{dotted decimal} per IPv4 e quello descritto in
-\secref{sec:IP_ipv6_notation} per IPv6.
-
-\index{socket|)}
-
-
-\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, ritorniamo con maggiori dettagli
-su una caratteristica delle funzioni di I/O che nel caso dei socket è
-particolarmente rilevante, e che ci tornerà utile anche in seguito.
-
-
-\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 per l'I/O su file; con i normali file di dati il
-problema si avverte solo quando si incontra la fine del file, ma in generale
-non è così.
-
-In questo caso tutto quello che il programma chiamante deve fare è di ripetere
-la lettura (o scrittura) per la quantità di byte rimanenti (e le funzioni si
-possono bloccare se i dati non sono disponibili): è lo stesso comportamento
-che si può avere scrivendo più di \const{PIPE\_BUF} byte in una pipe (si
-riveda quanto detto in \secref{sec:ipc_pipes}).
-
-\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 in \cite{UNP1}, 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 \figref{fig:sock_SockRead_code} e
-\figref{fig:sock_SockWrite_code} ed è disponibile fra i sorgenti allegati alla
-guida nei files \file{SockRead.c} e \file{SockWrite.c}.
-
-\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}
-
-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 è \errcode{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.
-
-Nel caso della lettura, se il numero di byte letti è zero, significa che si è
-arrivati alla fine del file (per i socket questo significa in genere che
-l'altro capo è stato chiuso, e non è quindi più possibile leggere niente) 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 \figref{fig:net_cli_code} è 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
-(\const{AF\_INET}), di tipo TCP \const{SOCK\_STREAM}. La funzione
-\func{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 \struct{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 \figref{fig:net_serv_code}, 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}
-
-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 \struct{sockaddr\_in}, anche in
-questo caso si usa la porta standard del servizio daytime, ma come indirizzo
-IP si il valore predefinito \const{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.
-
+può essere nullo e deve essere allocato precedentemente.
+
+
+
+
+
+% 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 endianness little endtest Mac
+% LocalWords:  Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
+% LocalWords:  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
 
 
 %%% Local Variables: