X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=e1390a11ac211f155e0d706fa6154adaf8d00aed;hp=613aea4de6e9afa31dfdbee8925dc179d4b01bc8;hb=99fa5a06cd27160cf673e3483ad552d32efa2c05;hpb=3f50b8e3fd683f710e34a88436109157d328e1b6

diff --git a/tcpsock.tex b/tcpsock.tex
index 613aea4..e1390a1 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -577,7 +577,7 @@ posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
 associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
 \cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
-definito in \headfile{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
+definito in \headfiled{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
 
 Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
 esterna non sono specificati; in questo caso la \textit{socket pair} associata
@@ -653,7 +653,7 @@ figlio e quelli che arrivano alla porta 21101 al secondo.
 In questa sezione descriveremo in maggior dettaglio le varie funzioni che
 vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
 funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
-precedente in sez.~\ref{sec:sock_socket}.
+precedente in sez.~\ref{sec:sock_creation}.
 
 
 \subsection{La funzione \func{bind}}
@@ -730,9 +730,9 @@ Si noti che si è usato \func{htonl} per assegnare il valore
 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-\itindex{endianness} l'\textit{endianness} della macchina, ed anche se esse
-possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
-norma usare sempre la funzione \func{htonl}.
+l'\textit{endianness} della macchina, ed anche se esse possono essere
+invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
+sempre la funzione \func{htonl}.
 
 \begin{table}[htb]
   \centering
@@ -743,8 +743,7 @@ norma usare sempre la funzione \func{htonl}.
     \hline
     \hline
     \const{INADDR\_ANY}      & Indirizzo generico (\texttt{0.0.0.0})\\
-    \const{INADDR\_BROADCAST}& Indirizzo di \itindex{broadcast}
-                               \textit{broadcast}.\\ 
+    \const{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\ 
     \const{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback}
                                (\texttt{127.0.0.1}).\\ 
     \const{INADDR\_NONE}     & Indirizzo errato.\\
@@ -761,7 +760,7 @@ con una struttura, perché il linguaggio C non consente l'uso di una struttura
 costante come operando a destra in una assegnazione.
 
 Per questo motivo nell'header \headfile{netinet/in.h} è definita una variabile
-\macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
+\macro{in6addr\_any} (dichiarata come \dirct{extern}, ed inizializzata dal
 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
 maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per
@@ -805,9 +804,8 @@ connessione con un server TCP,\footnote{di nuovo la funzione è generica e
   \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
     corretta nel relativo campo.
   \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
-    connessione ad un indirizzo \itindex{broadcast} \textit{broadcast} senza
-    che il socket fosse stato abilitato per il \itindex{broadcast}
-    \textit{broadcast}.
+    connessione ad un indirizzo \textit{broadcast} senza che il socket fosse
+    stato abilitato per il \textit{broadcast}.
   \end{errlist}
   altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
   \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
@@ -2039,17 +2037,17 @@ esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
 del segnale \signal{SIGCHLD} al padre, ma dato che non si è installato un
 gestore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di \itindex{zombie}
-\textit{zombie} (si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}),
-come risulterà ripetendo il comando \cmd{ps}:
+otterremo che il processo figlio entrerà nello stato di \textit{zombie} (si
+riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
+ripetendo il comando \cmd{ps}:
 \begin{verbatim}
  2356 pts/0    S      0:00 ./echod
  2359 pts/0    Z      0:00 [echod <defunct>]
 \end{verbatim}
 
-Dato che non è il caso di lasciare processi \itindex{zombie} \textit{zombie},
-occorrerà ricevere opportunamente lo stato di terminazione del processo (si
-veda sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
+Dato che non è il caso di lasciare processi \textit{zombie}, occorrerà
+ricevere opportunamente lo stato di terminazione del processo (si veda
+sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
 secondo quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al
 nostro server è pertanto quella di inserire la gestione della terminazione dei
 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
@@ -2070,9 +2068,9 @@ un errore di \errcode{EINTR}.
 
 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
 client, il processo figlio che gestisce la connessione terminerà, ed il padre,
-per evitare la creazione di \itindex{zombie} \textit{zombie}, riceverà il
-segnale \signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore
-però l'esecuzione nel padre ripartirà subito con il ritorno della funzione
+per evitare la creazione di \textit{zombie}, riceverà il segnale
+\signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore però
+l'esecuzione nel padre ripartirà subito con il ritorno della funzione
 \func{accept} (a meno di un caso fortuito in cui il segnale arriva durante
 l'esecuzione del programma in risposta ad una connessione) con un errore di
 \errcode{EINTR}. Non avendo previsto questa eventualità il programma considera