X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=e1390a11ac211f155e0d706fa6154adaf8d00aed;hp=19a9898e0a4a948c3fa70bcb291e1c4ac160fcbf;hb=99fa5a06cd27160cf673e3483ad552d32efa2c05;hpb=18f401b26dcb222f30925a0cf03cca8db52495cb

diff --git a/tcpsock.tex b/tcpsock.tex
index 19a9898..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}.}
@@ -1298,7 +1296,7 @@ Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
 byte restanti, tenendo conto che 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
+\const{PIPE\_BUF} byte in una \textit{pipe} (si riveda quanto detto in
 sez.~\ref{sec:ipc_pipes}).
 
 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
@@ -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
@@ -2491,12 +2489,12 @@ Per capire come questa avvenga comunque, non avendo inserito nel codice nessun
 controllo di errore, occorre ricordare che, a parte la bidirezionalità del
 flusso dei dati, dal punto di vista del funzionamento nei confronti delle
 funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
-pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che
-tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
-aperto il lettura il processo riceve un segnale di \signal{SIGPIPE}, e questo è
-esattamente quello che avviene in questo caso, e siccome non abbiamo un
-gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
-di terminare il processo.
+\textit{pipe}. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes},
+sappiamo che tutte le volte che si cerca di scrivere su una \textit{pipe} il
+cui altro capo non è aperto il lettura il processo riceve un segnale di
+\signal{SIGPIPE}, e questo è esattamente quello che avviene in questo caso, e
+siccome non abbiamo un gestore per questo segnale, viene eseguita l'azione
+preimpostata, che è quella di terminare il processo.
 
 Per gestire in maniera più corretta questo tipo di evento dovremo allora
 modificare il nostro client perché sia in grado di trattare le varie tipologie
@@ -2772,13 +2770,14 @@ sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
 sotto controllo è pronto per la relativa operazione.
 
 In quell'occasione non abbiamo però definito cosa si intende per pronto,
-infatti per dei normali file, o anche per delle pipe, la condizione di essere
-pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
-dei socket, visto che possono intervenire tutte una serie di possibili
-condizioni di errore dovute alla rete. Occorre allora specificare chiaramente
-quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}''
-quando viene passato come membro di uno dei tre \itindex{file~descriptor~set}
-\textit{file descriptor set} usati da \func{select}.
+infatti per dei normali file, o anche per delle \textit{pipe}, la condizione
+di essere pronti per la lettura o la scrittura è ovvia; invece lo è molto meno
+nel caso dei socket, visto che possono intervenire tutte una serie di
+possibili condizioni di errore dovute alla rete. Occorre allora specificare
+chiaramente quali sono le condizioni per cui un socket risulta essere
+``\textsl{pronto}'' quando viene passato come membro di uno dei tre
+\itindex{file~descriptor~set} \textit{file descriptor set} usati da
+\func{select}.
 
 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
 che un socket (che sarà riportato nel primo insieme di file descriptor) è