fatte getpw* e getgr*

[gapil.git] / simpltcp.tex

diff --git a/simpltcp.tex b/simpltcp.tex
index f7260cff817454a95a9cb9d550109a9d2c0c75df..4da8e81d70e17c58fea92b2fc1415d02df77ab49 100644 (file)
--- 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
 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}
 
 
 
 \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
 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.
 
 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
 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}
 
 \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
 
 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
 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à
 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}
 
 
 \subsection{La conclusione normale}


@@ -407,7 +407,16 @@ 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
 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: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: