Ropba di domenica e typo segnalato da Mirko.

diff --git a/ChangeLog b/ChangeLog
index 4ea9231a970c85c422c8d3ab2d2f8f37cf84d36b..03132de3ece39318b571af0da1bb449e1ee5e92e 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2005-02-28  Simone Piccardi  <piccardi@gont.earthsea.ea>
+
+       * ipc.tex: correzione typo segnalato da M. Maischberger.
+
 2005-01-12  Simone Piccardi  <piccardi@gont.earthsea.ea>
 
        * fileintro.tex: correzione typo segnalata da Alessio Frusciante

diff --git a/ipc.tex b/ipc.tex
index c241c773faf2d22ea1db29c02f1cecdd23371aeb..c86697143c8eef82abe367598b2a509e31e0e0bf 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -3762,7 +3762,7 @@ mascherati.
 
 In realtà a partire dal kernel 2.5.7 è stato introdotto un meccanismo di
 sincronizzazione completamente nuovo, basato sui cosiddetti
-\textit{futex}\footnote{la sigla sta per \textit{faxt user mode mutex}.}, con
+\textit{futex}\footnote{la sigla sta per \textit{fast user mode mutex}.}, con
 il quale dovrebbe essere possibile implementare una versione nativa dei
 semafori; esso è già stato usato con successo per reimplementare in maniera
 più efficiente tutte le direttive di sincronizzazione previste per i thread

diff --git a/sockctrl.tex b/sockctrl.tex
index 1cd043457c240ac118d42b42224d3bbdcc0b8941..592421dd07c0e84451161068797df5eb3ea6e893 100644 (file)
--- a/sockctrl.tex
+++ b/sockctrl.tex
@@ -2261,26 +2261,47 @@ allora il seguente:
   ma esistono ancora dei processi figli che mantengono attiva almeno una
   connessione remota che utilizza l'indirizzo locale; quando si riavvia il
   server questo viene bloccato sulla chiamata a \func{bind} dato che la porta
-  è ancora utilizzata in una connessione esistente.
-
-  Il punto più critico è che con il protocollo TCP questo può avvenire anche
-  dopo che l'ultimo processo figlio è terminato, in quanto la connessione può
-  restare attiva anche dopo la chiusura del socket mantenendosi nello stato
-  \texttt{TIME\_WAIT}. Usando \const{SO\_REUSEADDR} fra la chiamata a
-  \func{socket} e quella a \func{bind} si consente a quest'ultima di avere
-  successo anche in questo caso. È bene però ricordare che (si riveda quanto
-  detto in sez.~\ref{sec:TCP_time_wait}) la presenza dello stato
-  \texttt{TIME\_WAIT} ha una ragione, e che se si usa questa opzione esiste
-  sempre una probabilità, anche se estremamente remota,\footnote{perché ciò
-    avvenga infatti non solo devono coincidere gli indirizzi IP e le porte
-    degli estremi della nuova connessione, ma anche i numeri di sequenza dei
-    pacchetti, e questo è estremamente improbabile.}  che eventuali pacchetti
-  rimasti intrappolati in una precedente connessione possano finire fra quelli
-  di una nuova. 
-
-
-
-
+  è ancora utilizzata in una connessione esistente.\footnote{questa è una
+    delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
+    quanto è piuttosto comune in questa situazione quando si sta sviluppando
+    un server che si ferma e si riavvia in continuazione.}  Inoltre se si usa
+  il protocollo TCP questo può avvenire anche dopo che l'ultimo processo
+  figlio è terminato, dato che la connessione può restare attiva anche dopo la
+  chiusura del socket mantenendosi nello stato \texttt{TIME\_WAIT}. 
+
+  Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
+  \func{bind} si consente a quest'ultima di avere comunque successo anche se
+  la connessione è attiva (o nello stato texttt{TIME\_WAIT}). È bene però
+  ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
+  presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si
+  usa questa opzione esiste sempre una probabilità, anche se estremamente
+  remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
+    indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
+    numeri di sequenza dei pacchetti, e questo è estremamente improbabile.}
+  che eventuali pacchetti rimasti intrappolati in una precedente connessione
+  possano finire fra quelli di una nuova.
+
+  Il secondo caso in cui viene usata questa opzione è quando si ha una
+  macchina cui sono assegnati diversi numeri IP (o come suol dirsi
+  \textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
+  programma diverso (o una istanza diversa dello stesso programma) per
+  indirizzi IP diversi. Si ricordi infatti che è sempre possibile indicare a
+  \func{bind} di collegarsi solo su di un indirizzo specifico; in tal caso se
+  un altro programma cerca di riutilizzare la stessa porta (anche specificando
+  un indirizzo diverso) otterrà un errore a meno di non aver preventivamente
+  impostato \const{SO\_REUSEADDR}. Usando questa opzione diventa anche
+  possibile eseguire \func{bind} sull'indirizzo generico, e questo permetterà
+  il collegamento per tutti gli indirizzi (di quelli presenti) per i quali la
+  porta risulti libera. Infine si tenga presente che con il protocollo TCP non
+  è mai possibile far partire server che eseguano \func{bind} sullo stesso
+  indirizzo e la stessa porta, cioè ottenere quello che viene chiamato un
+  \textit{completely duplicate binding}.
+
+  Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
+  all'interno dello stesso programma per associare indirizzi diversi a socket
+  diversi. Vale in questo caso quanto detto in precedenza, l'unica differenza
+  è che in questo caso le diverse chiamate a  \func{bind} sono eseguite
+  all'interno dello stesso programma.
 
 
 \item[\const{SO\_TYPE}] questa opzione permette di leggere il tipo di socket