Ricominciato coi process group

[gapil.git] / socket.tex

diff --git a/socket.tex b/socket.tex
index a563c353642d1992a69f543386539f36c0d9db4e..a5af5da4c88f1f5fb8a0c8ecd3c2498b5f2c8505 100644 (file)
--- a/socket.tex
+++ b/socket.tex
@@ -8,7 +8,7 @@ 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 una introduzione puramente teorica
+utilizzerà per la comunicazione. Per evitare un'introduzione puramente teorica

 concluderemo il capitolo con un primo esempio di applicazione.
 
 \section{Una panoramica}
 concluderemo il capitolo con un primo esempio di applicazione.
 
 \section{Una panoramica}


@@ -22,14 +22,15 @@ con essi.
 \label{sec:sock_socket_def}
 
 Il \textit{socket}\footnote{una traduzione letterale potrebbe essere
 \label{sec:sock_socket_def}
 
 Il \textit{socket}\footnote{una traduzione letterale potrebbe essere

-  \textsl{manicotto}, 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
+  \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
 canale di comunicazione fra due processi su cui si possono leggere e scrivere

-dati analogo a quello di una pipe ma a differenza di questa e degli altri
-meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati
-alla comunicazione fra processi che girano sulla stessa macchina ma possono
-effettuare la comunicazione anche attraverso la rete.
+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
 
 Quella dei socket costituisce infatti la principale API (\textit{Application
   Program Interface}) usata nella programmazione di rete.  La loro origine


@@ -37,8 +38,8 @@ risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia 
 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
 sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
 siano state sviluppate interfacce alternative, originate dai sistemi SVr4,
 come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la

-diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
-flessibilità).
+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
 
 La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
 utilizzare i socket con i più disparati meccanismi di comunicazione, e non


@@ -57,11 +58,11 @@ usato, le funzioni da usare restano le stesse.
 
 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
 inutile, in quanto il comportamento di quest'ultima e le problematiche da
 
 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 ``stile'' di comunicazione
-usato.  La scelta di questo stile va infatti ad incidere sulla semantica che
-verrà utilizzata a livello utente per gestire la comunicazione (su come
-inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
-utilizzate.
+affrontare cambiano radicalmente a seconda dello \textsl{stile} di
+comunicazione usato.  La scelta di questo stile va infatti ad incidere sulla
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
+(su come inviare e ricevere i dati) e sul comportamento effettivo delle
+funzioni utilizzate.

 
 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
 
 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
 comunicazione che si vuole effettuare. Ad esempio alcuni stili di


@@ -115,7 +116,7 @@ socket, per cui viene messo a zero (con l'eccezione dei \textit{raw socket}).
   Apre un socket.
   
   \bodydesc{La funzione restituisce un intero positivo se riesce, e -1 se
   Apre un socket.
   
   \bodydesc{La funzione restituisce un intero positivo se riesce, e -1 se

-    fallisce, in quest'ultimo caso la variabile \var{errno} è settata con i
+    fallisce, in quest'ultimo caso la variabile \var{errno} è impostata con i

     seguenti codici di errore:
 
   \begin{errlist}
     seguenti codici di errore:
 
   \begin{errlist}


@@ -148,9 +149,10 @@ 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
 
 A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
 \texttt{AF\_} da \textit{address family}, e che identifica il formato degli

-indirizzi usati in quel dominio; le man pages di Linux si riferiscono a questi
-anche come \textit{name space}, (nome che però il manuale della glibc riserva
-ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
+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
 
 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


@@ -162,7 +164,7 @@ 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
 
 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
 indirizzi sono definiti dall'header \textit{socket.h}. In Linux le famiglie di

-protocolli disponibili sono riportate in \ntab.
+protocolli disponibili sono riportate in \tabref{tab:net_pf_names}.

 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize


@@ -175,7 +177,7 @@ protocolli disponibili sono riportate in \ntab.
        \macro{PF\_UNIX},
        \macro{PF\_LOCAL}  & Local communication            & unix(7)    \\
        \macro{PF\_INET}   & IPv4 Internet protocols        & ip(7)      \\
        \macro{PF\_UNIX},
        \macro{PF\_LOCAL}  & Local communication            & unix(7)    \\
        \macro{PF\_INET}   & IPv4 Internet protocols        & ip(7)      \\

-       \macro{PF\_INET6}  & IPv6 Internet protocols        &            \\
+       \macro{PF\_INET6}  & IPv6 Internet protocols        & ipv6(7)    \\

        \macro{PF\_IPX}    & IPX - Novell protocols         &            \\
        \macro{PF\_NETLINK}& Kernel user interface device   & netlink(7) \\
        \macro{PF\_X25}    & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\
        \macro{PF\_IPX}    & IPX - Novell protocols         &            \\
        \macro{PF\_NETLINK}& Kernel user interface device   & netlink(7) \\
        \macro{PF\_X25}    & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\


@@ -191,8 +193,8 @@ protocolli disponibili sono riportate in \ntab.
 
 Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
 esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere
 
 Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
 esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere

-creati solo da processi che hanno i privilegi di root (cioè effective uid
-uguale a zero) o la capability \macro{CAP\_NET\_RAW}.
+creati solo da processi che hanno i privilegi di root (cioè con userid
+effettivo uguale a zero) o con la capability \macro{CAP\_NET\_RAW}.

 
 
 \subsection{Il tipo, o stile}
 
 
 \subsection{Il tipo, o stile}


@@ -202,8 +204,9 @@ La scelta di un dominio non comporta per
 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
 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
 scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le

-glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
-glibc chiama \textit{styles}) definiti come \type{int} in \file{socket.h}:
+\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 \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati
 
 \begin{list}{}{}
 \item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati


@@ -225,10 +228,10 @@ glibc chiama \textit{styles}) definiti come \type{int} in \file{socket.h}:
 \item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato.
 \end{list}
 
 \item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato.
 \end{list}
 

-Si tenga presente che non tutte le combinazioni di famiglia di protocolli e
-tipo di socket sono valide, in quanto non è detto che nella famiglia esista un
-protocollo per tutti gli stili di comunicazione indicati qui sopra. Una
-tabella che mostra le combinazioni valide è la seguente:
+Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
+e un tipo di socket sono valide, in quanto non è detto che in una famiglia
+esista un protocollo per ciascuno dei diversi stili di comunicazione appena
+elencati.

 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize


@@ -266,9 +269,11 @@ tabella che mostra le combinazioni valide 
   \label{tab:sock_sock_valid_combinations}
 \end{table}
 
   \label{tab:sock_sock_valid_combinations}
 \end{table}
 

-Dove per ogni combinazione valida si è indicato il tipo di protocollo, o la
-parola \textsl{si} qualora non il protocollo non abbia un nome definito,
-mentre si sono lasciate vuote le caselle per le combinazioni non supportate.
+In \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.

 
 
 
 
 
 


@@ -300,10 +305,10 @@ attraverso puntatori (cio
 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
 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 nelle varie famiglie di protocolli; questo pone il problema di come passare
 questi puntatori, il C ANSI risolve questo problema coi i puntatori generici

-(i \type{void *}), ma l'interfaccia dei socket è antecedente alla
-definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
-una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata
-in \nfig:
+(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, \type{sockaddr}, che si è riportata in
+\figref{fig:sock_sa_gen_struct}.

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize


@@ -323,9 +328,9 @@ invocano dette funzioni passando l'indirizzo di un protocollo specifico
 occorrerà eseguire un casting del relativo puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 occorrerà eseguire un casting del relativo puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard

-POSIX.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
-definiti; la struttura è invece definita nell'include file
-\file{sys/socket.h}
+POSIX.1g, 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


@@ -345,16 +350,16 @@ definiti; la struttura 
     \hline
     \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
     \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
     \hline
     \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
     \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di

-    un socket& \type{sys/socket.h}\\
+    un socket& \file{sys/socket.h}\\

     \hline
     \hline

-    \type{in\_addr\_t} & indirizzo IPv4 (\file{uint32\_t}) & 
-    \type{netinet/in.h}\\
-    \type{in\_port\_t} & porta TCP o UDP (\file{uint16\_t})& 
-    \type{netinet/in.h}\\
+    \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & 
+    \file{netinet/in.h}\\
+    \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& 
+    \file{netinet/in.h}\\

     \hline
   \end{tabular}
   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 
     \hline
   \end{tabular}
   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 

-    stabilito dallo standard POSIX.1g}
+    stabilito dallo standard POSIX.1g.}

   \label{tab:sock_data_types}
 \end{table}
 
   \label{tab:sock_data_types}
 \end{table}
 


@@ -362,13 +367,13 @@ In alcuni sistemi la struttura 
 aggiuntivo \var{uint8\_t sin\_len} (come riportato da R. Stevens nei suoi
 libri). Questo campo non verrebbe usato direttamente dal programmatore e non è
 richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il campo
 aggiuntivo \var{uint8\_t sin\_len} (come riportato da R. Stevens nei suoi
 libri). Questo campo non verrebbe usato direttamente dal programmatore e non è
 richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il campo

-\type{sa\_family\_t} era storicamente un \type{unsigned short}.
+\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'
 diverse, in quanto esso usa il puntatore per recuperare il campo
 \var{sa\_family} con cui determinare il tipo di indirizzo; per questo
 
 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 \type{void *} sarebbe più immediato
+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.
 
 per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto
 l'uso di questa struttura.
 


@@ -379,8 +384,8 @@ l'uso di questa struttura.
 I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione
 attraverso internet; la struttura per gli indirizzi per un socket internet
 (IPv4) è definita come \type{sockaddr\_in} nell'header file
 I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione
 attraverso internet; la struttura per gli indirizzi per un socket internet
 (IPv4) è definita come \type{sockaddr\_in} nell'header file

-\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
-conforme allo standard POSIX.1g.
+\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.

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize


@@ -405,14 +410,14 @@ internet di un'interfaccia pi
 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
 prevede numeri di porta, che sono utilizzati solo dai protocolli di livello
 superiore come TCP e UDP. Questa struttura però viene usata anche per i socket
 RAW che accedono direttamente al livello di IP, nel qual caso il numero della

-porta viene settato al numero di protocollo.
+porta viene impostato al numero di protocollo.

 
 

-Il membro \var{sin\_family} deve essere sempre settato; \var{sin\_port}
+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
 specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; i numeri di
 porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da

-servizi standard. Soltanto processi con i privilegi di root (effective uid
-uguale a zero) o con la capability \macro{CAP\_NET\_BIND\_SERVICE} possono
-usare la funzione \func{bind} su queste porte.
+servizi standard. Soltanto processi con i privilegi di root (con userid
+effettivo uguale a zero) o con la capability \macro{CAP\_NET\_BIND\_SERVICE}
+possono usare la funzione \func{bind} su queste porte.

 
 Il membro \var{sin\_addr} contiene l'indirizzo internet dell'altro capo
 della comunicazione, e viene acceduto sia come struttura (un resto di una
 
 Il membro \var{sin\_addr} contiene l'indirizzo internet dell'altro capo
 della comunicazione, e viene acceduto sia come struttura (un resto di una


@@ -430,7 +435,7 @@ 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 una estensione di IPv4 i socket di tipo \macro{PF\_INET6} sono
+Essendo IPv6 un'estensione di IPv4 i socket di tipo \macro{PF\_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}.
 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}.


@@ -455,7 +460,7 @@ 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 settato ad
+Il campo \var{sin6\_family} deve essere sempre impostato ad

 \macro{AF\_INET6}, il campo \var{sin6\_port} è analogo a quello di IPv4 e
 segue le stesse regole; il campo \var{sin6\_flowinfo} è a sua volta diviso
 in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i
 \macro{AF\_INET6}, il campo \var{sin6\_port} è analogo a quello di IPv4 e
 segue le stesse regole; il campo \var{sin6\_flowinfo} è a sua volta diviso
 in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i


@@ -606,7 +611,7 @@ I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad

-indicare i tipi di dato (\type{long} o \type{short}, riportati anche dai
+indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai

 prototipi).
 
 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
 prototipi).
 
 Usando queste funzioni si ha la conversione automatica: nel caso in cui la


@@ -676,7 +681,7 @@ e \textit{numeric}.
 
 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
 indirizzo e può essere \macro{AF\_INET} o \macro{AF\_INET6}. Se la famiglia
 
 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
 indirizzo e può essere \macro{AF\_INET} o \macro{AF\_INET6}. Se la famiglia

-indicata non è valida entrambe le funzioni settano la variabile \var{errno}
+indicata non è valida entrambe le funzioni impostano la variabile \var{errno}

 al valore \macro{EAFNOSUPPORT}. I prototipi delle suddette funzioni sono i
 seguenti:
 \begin{prototype}{sys/socket.h}
 al valore \macro{EAFNOSUPPORT}. I prototipi delle suddette funzioni sono i
 seguenti:
 \begin{prototype}{sys/socket.h}


@@ -698,7 +703,7 @@ seguenti:
  
   \bodydesc{La funzione restituisce un puntatore non nullo a \var{dest} in
     caso di successo e un puntatore nullo in caso di fallimento, in
  
   \bodydesc{La funzione restituisce un puntatore non nullo a \var{dest} in
     caso di successo e un puntatore nullo in caso di fallimento, in

-    quest'ultimo caso viene settata la variabile \var{errno} con il valore
+    quest'ultimo caso viene impostata la variabile \var{errno} con il valore

     \macro{ENOSPC} in caso le dimensioni dell'indirizzo eccedano la lunghezza
     specificata da \var{len} o \macro{ENOAFSUPPORT} in caso \var{af} non sia
     una famiglia di indirizzi valida.}
     \macro{ENOSPC} in caso le dimensioni dell'indirizzo eccedano la lunghezza
     specificata da \var{len} o \macro{ENOAFSUPPORT} in caso \var{af} non sia
     una famiglia di indirizzi valida.}


@@ -835,9 +840,10 @@ successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
 definizioni precise e dettagli di funzionamento che saranno trattati
 estensivamente più avanti.
 
 definizioni precise e dettagli di funzionamento che saranno trattati
 estensivamente più avanti.
 

-In \nfig\ è riportata la sezione principale del codice del nostro client
-elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richiesta.
+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{figure}[!htb]
   \footnotesize


@@ -912,7 +918,7 @@ Il primo passo (\texttt{\small 14--18}) 
 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
 stampa un errore con la relativa routine e si esce.
 
 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 una apposita
+Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita

 struttura \type{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
 il numero della porta del servizio. Il primo passo è inizializzare tutto a
 zero, per poi inserire il tipo di protocollo e la porta (usando per
 struttura \type{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
 il numero della porta del servizio. Il primo passo è inizializzare tutto a
 zero, per poi inserire il tipo di protocollo e la porta (usando per


@@ -957,7 +963,7 @@ necessario deve provvedere il programma stesso.
 
 Dopo aver illustrato il client daremo anche un esempio di un server
 elementare, in grado di rispondere al precedente client. Il listato è
 
 Dopo aver illustrato il client daremo anche un esempio di un server
 elementare, in grado di rispondere al precedente client. Il listato è

-nuovamente mostrato in \nfig, il sorgente completo
+nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo

 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
 directory \file{sources}.
 
 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
 directory \file{sources}.
 


@@ -1069,3 +1075,8 @@ 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.
 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
 attiva e il terminale da cui lo si è lanciato è stato sconnesso),
 occorrerebbero delle opportune modifiche.

+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: