From 5b8f42ef99d2884ca02331ee61649ce3b6ec18f5 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 28 Feb 2005 19:06:50 +0000 Subject: [PATCH] Ropba di domenica e typo segnalato da Mirko. --- ChangeLog | 4 ++++ ipc.tex | 2 +- sockctrl.tex | 61 +++++++++++++++++++++++++++++++++++----------------- 3 files changed, 46 insertions(+), 21 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4ea9231..03132de 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2005-02-28 Simone Piccardi + + * ipc.tex: correzione typo segnalato da M. Maischberger. + 2005-01-12 Simone Piccardi * fileintro.tex: correzione typo segnalata da Alessio Frusciante diff --git a/ipc.tex b/ipc.tex index c241c77..c866971 100644 --- 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 1cd0434..592421d 100644 --- 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 -- 2.30.2