X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=simpltcp.tex;h=4da8e81d70e17c58fea92b2fc1415d02df77ab49;hp=c119df0a2bba2035a61d1a768c3ce586d26133de;hb=105bd8930572cf5885b4482966754d9af0597874;hpb=fd934ebcf645120b9c92a434ab6b8755c04a3c07

diff --git a/simpltcp.tex b/simpltcp.tex
index c119df0..4da8e81 100644
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -8,13 +8,13 @@ comunicazione in entrambe le direzioni.
 Inoltre prenderemo in esame, oltre al comportamento in condizioni normali,
 anche tutti i possibili scenari particolari (errori, sconnessione della rete,
 crash del client o del server durante la connessione) che possono avere luogo
-durante l'impiego di una applicazione di rete.
+durante l'impiego di un'applicazione di rete.
 
 
 \section{Il servizio \texttt{echo}}
 \label{sec:TCPsimp_echo}
 
-L'applicazione scelta come esempio sarà una implementazione elementare, ma
+L'applicazione scelta come esempio sarà un'implementazione elementare, ma
 completa, del servizio \texttt{echo}. Il servizio \texttt{echo} è uno dei
 servizi standard solitamente provvisti direttamente dal superserver
 \cmd{inetd}, ed è definito dall'RFC~862. Come dice il nome il servizio deve
@@ -29,16 +29,16 @@ caratteri dallo standard input e la scrive sul server, il server legger
 linea dalla connessione e la riscriverà all'indietro; sarà compito del client
 leggere la risposta del server e stamparla sullo standard output.
 
-Si è scelto di usare questo servizio, seguendo lo Stevens, perché costituisce
-il prototipo ideale di una generica applicazione di rete in cui un server
-risponde alle richieste di un client; tutto quello che cambia nel caso si una
-applicazione più complessa è la elaborazione dell'input del client da parte
-del server nel fornire le risposte in uscita. 
+Si è scelto di usare questo servizio, seguendo l'esempio di \cite{UNP1},
+perché costituisce il prototipo ideale di una generica applicazione di rete in
+cui un server risponde alle richieste di un client; tutto quello che cambia
+nel caso si una applicazione più complessa è la elaborazione dell'input del
+client da parte del server nel fornire le risposte in uscita.
 
-Partiremo da una implementazione elementare che dovrà essere rimaneggiata di
+Partiremo da un'implementazione elementare che dovrà essere rimaneggiata di
 volta in volta per poter tenere conto di tutte le evenienze che si possono
-manifestare nella vita reale di una applicazione di rete, fino ad arrivare ad
-una implementazione completa.
+manifestare nella vita reale di un'applicazione di rete, fino ad arrivare ad
+un'implementazione completa.
 
 \subsection{La struttura del server}
 \label{sec:TCPsimp_server_main}
@@ -262,7 +262,7 @@ il client esce.
 
 Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
 di considerare in dettaglio tutte le problematiche che si possono incontrare
-nello scrivere una applicazione di rete. Infatti attraverso l'esame delle sue
+nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
 modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
 che avviene nelle varie situazioni limite, da una parte potremo approfondire
 la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
@@ -329,11 +329,11 @@ un risultato del tipo:
 tre processi, tutti in stato di \textit{sleep} (S).
 
 Se a questo punto si inizia a scrivere qualcosa sul client niente sarà
-trasmesso fin tanto che non si prema il ritorno carrello, allora la
-\func{fgets} ritornerà e a questo punto il client scriverà quanto immesso
-sul socket, poi rileggerà quanto gli viene inviato all'indietro dal server, e
-questo sarà inviato sullo standard output, che nel caso ne provoca
-l'immediatamente stampa a video.
+trasmesso fin tanto che non si prema il ritorno carrello (si ricordi quanto
+trattato in \secref{sec:file_line_io}), allora la \func{fgets} ritornerà e a
+questo punto il client scriverà quanto immesso sul socket, poi rileggerà
+quanto gli viene inviato all'indietro dal server, e questo sarà inviato sullo
+standard output, che nel caso ne provoca l'immediatamente stampa a video.
 
 
 \subsection{La conclusione normale}
@@ -407,9 +407,13 @@ ripetendo il comando \cmd{ps}:
 Poiché non è possibile lasciare processi zombie che pur inattivi occupano
 spazio nella tabella dei processi e a lungo andare saturerebbero le risorse
 del kernel, occorrerà ricevere opportunamente lo stato di terminazione del
-processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando il
-segnale, per questo installeremo un manipolatore usando la funzione
-\func{Signal} (trattata in dettaglio in \secref{sec:sig_signal}).
+processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando
+\macro{SIGCHLD} secondo quanto illustrato in \secref{sec:sig_sigchld}.
+
+La prima modifica al nostro server è pertanto quella di inserire la gestione
+della terminazione dei processi figli attraverso l'uso di un manipolatore.
+Per questo usiamo la funzione \code{Signal} illustrata in
+\figref{fig:sig_Signal_code}. 
 
 
 %%% Local Variables: