Nuova vesione divisa in due parti.
[gapil.git] / socket.tex
index 2e34e78d3bdeaaa3bab7428c8740310ecc3b36ec..5a2a8ea15a29165e53655f5f6aa8a8272a7c04b2 100644 (file)
 \chapter{Introduzione ai socket}
 \label{cha:socket_intro}
 
 \chapter{Introduzione ai socket}
 \label{cha:socket_intro}
 
-In questo capitolo inizieremo a spiegare le caratteristiche principali della
+In questo capitolo inizieremo a spiegare le caratteristiche salienti della
 principale interfaccia per la programmazione di rete, quella dei
 principale interfaccia per la programmazione di rete, quella dei
-\textit{socket}, che pur essendo nata in unix è usata ormai da tutti i sistemi
-operativi.
+\textit{socket}, che, pur essendo nata in ambiente Unix è usata ormai da tutti
+i sistemi operativi.
 
 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
 come creare un socket e come collegarlo allo specifico protocollo di rete che
 
 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
 come creare un socket e come collegarlo allo specifico protocollo di rete che
-utilizzerà per la comunicazione. Per evitare un'introduzione puramente teorica
-concluderemo il capitolo con un primo esempio di applicazione.
+si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
+teorica concluderemo il capitolo con un primo esempio di applicazione.
 
 \section{Una panoramica}
 \label{sec:sock_overview}
 
 \section{Una panoramica}
 \label{sec:sock_overview}
@@ -33,30 +33,30 @@ con essi.
 \subsection{I \textit{socket}}
 \label{sec:sock_socket_def}
 
 \subsection{I \textit{socket}}
 \label{sec:sock_socket_def}
 
-Il \textit{socket}\footnote{una traduzione letterale potrebbe essere
+I \textit{socket}\footnote{una traduzione letterale potrebbe essere
   \textsl{presa}, ma essendo universalmente noti come socket utilizzeremo
   \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
+  sempre la parola inglese.} sono uno dei principali meccanismi di
+comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati in
+\secref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione fra
+processi. Un socket costituisce in sostanza un canale di comunicazione fra due
+processi su cui si possono leggere e scrivere dati analogo a quello di una
+pipe (vedi \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
+realizzare la comunicazione anche attraverso la rete.
+
+Quella dei socket costituisce infatti la principale interfaccia usata nella
+programmazione di rete.  La loro origine risale al 1983, quando furono
+introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
+piccole modifiche, negli anni successivi. Benché siano state sviluppate
+interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
+  Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
+di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
+
+La flessibilità e la genericità dell'interfaccia inoltre consente di
 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
 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.
+solo con la suite dei protocolli TCP/IP, anche se questa sarà comunque quella
+di cui tratteremo in maniera più estesa.
 
 
 \subsection{Concetti base}
 
 
 \subsection{Concetti base}
@@ -87,9 +87,9 @@ inviati, o inviare dei pacchetti pi
 
 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
 
 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
+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 \textit{broadcast} come per la
 radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove
 chiunque si collega possa riceverli.
 
 radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove
 chiunque si collega possa riceverli.
 
@@ -154,58 +154,88 @@ attraverso i quali si vuole effettuare la comunicazione.
 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
 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 inizia con una costante che inizia
+per \texttt{PF\_}, iniziali di \textit{protocol family}, un altro nome con cui
+si indicano i domini.
+
+A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
+associato ad una costante, che inizia invece per \texttt{AF\_} (da
+\textit{address family}) che identifica il formato degli indirizzi usati in
+quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
+anche come \textit{name space},\footnote{nome che invece il manuale delle
+  \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
+identificano il formato degli indirizzi usati in quel dominio per identificare
+i capi della comunicazione.
 
 \begin{table}[htb]
   \footnotesize
   \centering
 
 \begin{table}[htb]
   \footnotesize
   \centering
-  \begin{tabular}[c]{|l|l|l|}
+  \begin{tabular}[c]{|l|l|l|l|}
        \hline
        \hline
-       \textbf{Nome}      & \textbf{Utilizzo}           &\textbf{Man page} \\
+       \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
        \hline
        \hline
        \hline
        \hline
-       \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)  \\    
+       \const{PF\_UNSPEC}   & 0& Non specificato               &            \\
+       \const{PF\_LOCAL}    & 1& Local communication           & unix(7)    \\
+       \const{PF\_UNIX}, \const{PF\_FILE}&1&                   &            \\
+       \const{PF\_INET}     & 2& IPv4 Internet protocols       & ip(7)      \\
+       \const{PF\_AX25}     & 3& Amateur radio AX.25 protocol  &            \\
+       \const{PF\_IPX}      & 4& IPX - Novell protocols        &            \\
+       \const{PF\_APPLETALK}& 5& Appletalk                     & ddp(7)     \\
+       \const{PF\_NETROM}   & 6& Amateur radio NetROM          &            \\
+       \const{PF\_BRIDGE}   & 7& Multiprotocol bridge          &            \\
+       \const{PF\_ATMPVC}   & 8& Access to raw ATM PVCs        &            \\
+       \const{PF\_X25}      & 9& ITU-T X.25 / ISO-8208 protocol& x25(7)     \\
+       \const{PF\_INET6}    &10& IPv6 Internet protocols       & ipv6(7)    \\
+       \const{PF\_ROSE}     &11& Amateur Radio X.25 PLP        &            \\
+       \const{PF\_DECnet}   &12& Reserved for DECnet project   &            \\
+       \const{PF\_NETBEUI}  &13& Reserved for 802.2LLC project &            \\
+       \const{PF\_SECURITY} &14& Security callback pseudo AF   &            \\
+       \const{PF\_KEY}      &15& PF\_KEY key management API    &            \\
+       \const{PF\_NETLINK}  &16& Kernel user interface device  & netlink(7) \\
+       \const{PF\_PACKET}   &17& Low level packet interface    & packet(7)  \\
+       \const{PF\_ASH}      &18& Ash                           &    \\
+       \const{PF\_ECONET}   &19& Acorn Econet                  &    \\
+       \const{PF\_ATMSVC}   &20& ATM SVCs                      &    \\
+       \const{PF\_SNA}      &22& Linux SNA Project             &    \\
+       \const{PF\_IRDA}     &23& IRDA sockets                  &    \\
+       \const{PF\_PPPOX}    &24& PPPoX sockets                 &    \\
+       \const{PF\_WANPIPE}  &25& Wanpipe API sockets           &    \\
+       \const{PF\_BLUETOOTH}&31& Bluetooth sockets             &    \\
        \hline
   \end{tabular}
        \hline
   \end{tabular}
-  \caption{Famiglie di protocolli definiti in Linux}
+  \caption{Famiglie di protocolli definiti in Linux.}
   \label{tab:net_pf_names}
 \end{table}
 
   \label{tab:net_pf_names}
 \end{table}
 
-Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
-esempio in generale tutti i socket di tipo \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}.
+L'idea alla base della distinzione fra questi due insiemi di costanti era che
+una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
+il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
+il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
+quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
+famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
+nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
+valori numerici.\footnote{in Linux, come si può verificare andando a guardare
+  il contenuto di \file{bits/socket.h} le costanti sono esattamente le stesse
+  e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
+  lo stesso nome.}
+
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+indirizzi, sono definiti dall'header \textit{socket.h}. Un elenco delle
+famiglie di protocolli disponibili in Linux è riportato in
+\tabref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
+  definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
+  compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
+  viene definita anche una costante \const{PF\_MAX} che indica il valore
+  massimo associabile ad un dominio (nel caso 32).}
+
+Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
+dall'utente generico, ad esempio in generale tutti i socket di tipo
+\const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
+di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
+capability \texttt{CAP\_NET\_RAW}.
 
 
 \subsection{Il tipo, o stile}
 
 
 \subsection{Il tipo, o stile}
@@ -213,31 +243,32 @@ effettivo uguale a zero) o con la capability \texttt{CAP\_NET\_RAW}.
 
 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
 
 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
+utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
+socket permette di scegliere lo stile di comunicazione indicando il tipo di
+socket con l'argomento \param{type} di \func{socket}. Linux mette a
+disposizione vari tipi di socket (che corrispondono a quelli che il manuale
+della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
+seguenti costanti:
+
+\begin{basedescript}{\desclabelwidth{2.8cm}\desclabelstyle{\nextlinelabel}}
+\item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
-  byte (da cui il nome \textit{stream}). 
-\item \const{SOCK\_DGRAM} Viene usato per mandare pacchetti di lunghezza
+  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. 
   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
+\item[\const{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).
   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
+\item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
   rete e alle varie interfacce. I normali programmi di comunicazione non
   devono usarlo.
   rete e alle varie interfacce. I normali programmi di comunicazione non
   devono usarlo.
-\item \const{SOCK\_RDM} Provvede un canale di trasmissione di pacchetti
+\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di pacchetti
   affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
   affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
-\item \const{SOCK\_PACKET} Obsoleto, non deve essere usato.
-\end{list}
+\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere usato.
+\end{basedescript}
 
 Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
 e un tipo di socket sono valide, in quanto non è detto che in una famiglia
 
 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
@@ -281,11 +312,10 @@ elencati.
 \end{table}
 
 In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
 \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.
-
+valide possibili per le principali famiglie di protocolli. Per ogni
+combinazione valida si è indicato il tipo di protocollo, o la parola
+\textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
+sono lasciate vuote le caselle per le combinazioni non supportate.
 
 
 \section{Le strutture degli indirizzi dei socket}
 
 
 \section{Le strutture degli indirizzi dei socket}
@@ -297,15 +327,13 @@ 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.
 
 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}
 
 
 \subsection{La struttura generica}
@@ -315,11 +343,11 @@ Le strutture degli indirizzi vengono sempre passate alle varie funzioni
 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
 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 \figref{fig:sock_sa_gen_struct}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -339,12 +367,13 @@ 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
 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 coversione (il \textit{casting}) del relativo
+puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
-POSIX.1g, riassunti in \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 \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}.
 
 \begin{table}[!htb]
   \centering
 
 \begin{table}[!htb]
   \centering
@@ -379,10 +408,10 @@ include in cui sono definiti; la struttura 
 \end{table}
 
 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
 \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}.
+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
 di fare da riferimento per il casting, per il kernel le cose sono un po'
 
 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'
@@ -397,9 +426,9 @@ l'uso di questa struttura.
 \label{sec:sock_sa_ipv4}
 
 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
 \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
+attraverso internet; la struttura per gli indirizzi per un socket internet (se
+si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
+\file{netinet/in.h} ed ha la forma mostrata in
 \figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
 \begin{figure}[!htb]
 \figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
 \begin{figure}[!htb]
@@ -429,19 +458,24 @@ superiore come TCP e UDP. Questa struttura per
 RAW che accedono direttamente al livello di IP, nel qual caso il numero della
 porta viene impostato al numero di protocollo.
 
 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
+Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
+altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
+specifica il \textsl{numero di porta} (affronteremo in dettaglio in le
+\textsl{porte} in \secref{sec:TCPel_port_num}). I numeri di porta sotto il
+1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi standard
+e soltanto processi con i privilegi di amministratore (con user-ID effettivo
+uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
+usare la funzione \func{bind} (che vedremo in \secref{sec:TCPel_func_bind}) su
+queste porte.
+
+Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
+come struttura (un resto di una implementazione precedente in cui questa era
+una \direct{union} usata per accedere alle diverse classi di indirizzi) che
+direttamente come intero. In \file{netinet/in.h} vengono definiti anche alcune
+costanti per alcuni indirizzi speciali, che vedremo in
+\tabref{tab:TCPel_ipv4_addr}.
+
+Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
 essere specificati in quello che viene chiamato \textit{network order}, cioè
 con i bit ordinati in formato \textit{big endian}, questo comporta la
 necessità di usare apposite funzioni di conversione per mantenere la
 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
@@ -452,10 +486,11 @@ problema e le relative soluzioni).
 \subsection{La struttura degli indirizzi IPv6}
 \label{sec:sock_sa_ipv6}
 
 \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{PF\_INET6} sono
 sostanzialmente identici ai precedenti; la parte in cui si trovano
 sostanzialmente identici ai precedenti; la parte in cui si trovano
-praticamente tutte le differenze è quella della struttura degli indirizzi. La
-struttura degli indirizzi è definita ancora in \file{netinet/in.h}.
+praticamente tutte le differenze fra i due socket è quella della struttura
+degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
+in \figref{fig:sock_sa_ipv6_struct}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -479,21 +514,22 @@ struct in6_addr {
   \label{fig:sock_sa_ipv6_struct}
 \end{figure}
 
   \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\_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.
+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\_addr} contiene l'indirizzo a 128 bit usato da IPv6, infine
+il campo \var{sin6\_scope\_id} è un campo introdotto in Linux 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.
+Si noti che questa struttura è più grande della \struct{sockaddr} generica
+vista in \figref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non
+avere fatto assunzioni riguardo alla possibilità di contenere i dati nelle
+dimensioni di quest'ultima.
 
 
 \subsection{La struttura degli indirizzi locali}
 
 
 \subsection{La struttura degli indirizzi locali}
@@ -523,13 +559,79 @@ struct sockaddr_un {
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
-In questo caso il campo \var{sun\_family} deve essere \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 \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 (mantenuta 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).
+
+
+\subsection{La struttura degli indirizzi AppleTalk}
+\label{sec:sock_sa_appletalk}
+
+I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
+\file{netatalk} per implementare la comunicazione secondo il protocollo
+AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
+computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
+kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
+opportuno usare le funzioni di libreria, si tratta 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} è \func{ATPROTO\_DDP}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct sockaddr_atalk {
+    sa_family_t     sat_family; /* address family */
+    u_char          sat_port;   /* port */
+    struct at_addr  sat_addr;   /* net/node */
+};
+
+struct at_addr {
+    unsigned short  s_net;
+    unsigned char   s_node;
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \caption{La struttura degli indirizzi dei socket AppleTalk 
+    \structd{sockaddr\_atalk}.}
+  \label{fig:sock_sa_atalk_struct}
+\end{figure}
+
+Il campo \var{sut\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
+campo \var{sun\_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 capability
+\const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
+struttura \var{sun\_addr}, e deve essere in \textit{network order}; esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+valore \const{AT\_ANYNET}, che indica una rete genrica e vale anche per
+indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
+può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
+corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
+rete.
+
+
+
+
+
+\subsection{La struttura degli indirizzi DECnet}
+\label{sec:sock_sa_decnet}
+
+I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
+Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
+fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è di
+compatibilità con macchine che stanno comunque scomparendo. Lo si riporta solo
+come esempio 
+
 
 
 % \subsection{Il passaggio delle strutture}
 
 
 % \subsection{Il passaggio delle strutture}
@@ -569,12 +671,12 @@ utile anche in seguito.
 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
 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).
+variabili intere (ed in genere 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
 
 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
+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
 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
@@ -586,8 +688,8 @@ 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},
 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}.
+altri esempi di uso di questi formati sono quello del bus PCI, che è
+\textit{little endian}, o quello del bus VME che è \textit{big endian}.
 
 Esistono poi anche dei processori che possono scegliere il tipo di formato
 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
 
 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
@@ -603,7 +705,7 @@ Il problema connesso all'endianess\index{endianess} 
 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
 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
+invertito l'ordine di lettura per cui, per riavere il valore originale,
 dovranno essere rovesciati.
 
 Per questo motivo si usano delle funzioni di conversione che servono a tener
 dovranno essere rovesciati.
 
 Per questo motivo si usano delle funzioni di conversione che servono a tener
@@ -658,7 +760,7 @@ dei numeri IP che si usa normalmente.
 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
 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
+\texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
   order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
 \funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
   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: