X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=simpltcp.tex;h=d723e308d32ff3c36296e66c91a7ec4ddd5aa4ba;hp=b9d99e64afb8a46e54fa97de01dc9a66771fd6b3;hb=25de957ddf731370bec1eb74b13cf35aa7886d1b;hpb=247c7ba624f39b283f9e85816c0616348f39c1b6

diff --git a/simpltcp.tex b/simpltcp.tex
index b9d99e6..d723e30 100644
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -1,3 +1,13 @@
+%% simpltcp.tex
+%%
+%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
 \chapter{Un esempio completo di client/server TCP}
 \label{cha:simple_TCP_sock}
 
@@ -121,14 +131,15 @@ alla funzione \code{ServEcho}.
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 
-Il codice della funzione \code{ServEcho} è invece mostrata in \nfig, la
-comunicazione viene gestita all'interno del ciclo (linee \texttt{\small
-  6--8}).  I dati inviati dal client vengono letti dal socket con una semplice
-\func{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura
-viene invece gestita dalla funzione \func{SockWrite} (descritta in
-\figref{fig:sock_SockWrite_code}) che si incarica di tenere conto
-automaticamente della possibilità che non tutti i dati di cui è richiesta la
-scrittura vengano trasmessi con una singola \func{write}.
+Il codice della funzione \code{ServEcho} è invece mostrata in
+\figref{fig:TCPsimpl_server_elem_sub}, la comunicazione viene gestita
+all'interno del ciclo (linee \texttt{\small 6--8}).  I dati inviati dal client
+vengono letti dal socket con una semplice \func{read} (che ritorna solo in
+presenza di dati in arrivo), la riscrittura viene invece gestita dalla
+funzione \func{SockWrite} (descritta in \figref{fig:sock_SockWrite_code}) che
+si incarica di tenere conto automaticamente della possibilità che non tutti i
+dati di cui è richiesta la scrittura vengano trasmessi con una singola
+\func{write}.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -242,7 +253,7 @@ La funzione utilizza due buffer per gestire i dati inviati e letti sul socket
 (linee \texttt{\small 5--10}), i dati da inviare sulla connessione vengono
 presi dallo \file{stdin} usando la funzione \func{fgets} che legge una
 linea di testo (terminata da un \texttt{CR} e fino al massimo di
-\macro{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione
+\const{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione
 \func{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo
 l'invio multiplo qualora una singola \func{write} non basti, come spiegato
 in \secref{sec:sock_io_behav}).
@@ -396,22 +407,22 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
-segnale \macro{SIGCHLD} al padre, ma dato che non si è installato un
+segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
 manipolatore 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 zombie (si riveda
-quanto illustrato in \secref{sec:sig_sigchld}), come risulterà ripetendo il
-comando \cmd{ps}:
+otterremo che il processo figlio entrerà nello stato di zombie\index{zombie}
+(si riveda quanto illustrato in \secref{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}
 
-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
-\macro{SIGCHLD} secondo quanto illustrato in \secref{sec:sig_sigchld}.
+Poiché non è possibile lasciare processi zombie\index{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
+\const{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.
@@ -430,7 +441,7 @@ riceve i segnali dei processi figli terminati gi
 \noindent
 all'esempio illustrato in \figref{fig:TCPsimpl_serv_code}, e linkando il tutto
 alla funzione \code{sigchld\_hand}, si risolverà completamente il problema
-degli zombie.
+degli zombie\index{zombie}.