Modifiche varie e ripulitura esempi. Trattata accept4.
authorSimone Piccardi <piccardi@gnulinux.it>
Thu, 6 Oct 2016 12:03:15 +0000 (12:03 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Thu, 6 Oct 2016 12:03:15 +0000 (12:03 +0000)
listati/TCP_daytime.c
listati/TCP_echod_first.c
listati/TCP_echod_first_init.c [new file with mode: 0644]
listati/TCP_echod_first_main.c [new file with mode: 0644]
listati/TCP_iter_daytimed.c
sources/TCP_daytime.c
sources/TCP_echo_first.c
sources/TCP_iter_daytimed.c
tcpsock.tex

index e1459d9abe6994f445db485819a2aa7954181aa8..708ae32ea61edb9fee6a7a18ba89c3b48bb8a530 100644 (file)
@@ -1,8 +1,9 @@
-#include <sys/types.h>   /* predefined types */
+#include <stdlib.h>   /* predefined types */
 #include <unistd.h>      /* include unix standard library */
 #include <arpa/inet.h>   /* IP addresses conversion utilities */
 #include <sys/socket.h>  /* socket library */
 #include <stdio.h>       /* include standard I/O library */
+#include <string.h>     /* C strings library */
 
 int main(int argc, char *argv[])
 {
index 0da60a6eb584af77e7ef602a1427baa39e1a9d50..2fb50a3a91ad37e2cdc37eda841c50289be92b6f 100644 (file)
@@ -4,12 +4,11 @@ int main(int argc, char *argv[])
     pid_t pid;
     struct sockaddr_in serv_add;
     ...
-    /* create socket */
+    /* create and init socket */
     if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
        perror("Socket creation error");
        exit(1);
     }
-    /* initialize address and bind socket */
     memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
     serv_add.sin_family = AF_INET;                  /* address type is INET */
     serv_add.sin_port = htons(7);                   /* echo port is 7 */
diff --git a/listati/TCP_echod_first_init.c b/listati/TCP_echod_first_init.c
new file mode 100644 (file)
index 0000000..02e99ad
--- /dev/null
@@ -0,0 +1,36 @@
+int main(int argc, char *argv[])
+{
+    int list_fd, conn_fd; 
+    pid_t pid;
+    struct sockaddr_in serv_add;
+    ...
+    /* create and init socket */
+    if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
+       perror("Socket creation error");
+       exit(1);
+    }
+    memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
+    serv_add.sin_family = AF_INET;                  /* address type is INET */
+    serv_add.sin_port = htons(7);                   /* echo port is 7 */
+    serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
+    if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
+       perror("bind error");
+       exit(1);
+    }
+    /* give away privileges and go daemon */
+    if (setgid(65534) !=0) { /* first give away group privileges */
+       perror("cannot give away group privileges");
+       exit(1);
+    }
+    if (setuid(65534) !=0) { /* and only after user ... */
+       perror("cannot give away user privileges");
+       exit(1);
+    }
+    if (demonize) {          /* go daemon */
+        openlog(argv[0], 0, LOG_DAEMON); /* open logging */
+       if (daemon(0, 0) != 0) {
+           perror("cannot start as daemon");
+           exit(1);
+       }
+    }
+    ...
diff --git a/listati/TCP_echod_first_main.c b/listati/TCP_echod_first_main.c
new file mode 100644 (file)
index 0000000..3f69e89
--- /dev/null
@@ -0,0 +1,26 @@
+    ...
+    /* main body */
+    if (listen(list_fd, BACKLOG) < 0 ) { /* listen on socket */
+       PrintErr("listen error");
+       exit(1);
+    }
+    while (1) {                          /* handle echo to client */
+       len = sizeof(cli_add);
+       if ( (conn_fd = accept(list_fd, NULL, NULL)) < 0) { 
+           PrintErr("accept error");
+           exit(1);
+       }
+       if ( (pid = fork()) < 0 ) {      /* fork to handle connection */
+           PrintErr("fork error");
+           exit(1);
+       }
+       if (pid == 0) {      /* child */
+           close(list_fd);          /* close listening socket */   
+           ServEcho(conn_fd);       /* handle echo */
+           exit(0);
+       } else {             /* parent */
+           close(conn_fd);          /* close connected socket */
+       }
+    }
+    exit(0);     /* normal exit, never reached */
+}
index 5f9b116c30fcf2fe9444729eed73e15081a657a4..e0b9b15f8865f594728d8f59d6643ce8cbc57d20 100644 (file)
@@ -1,9 +1,3 @@
-#include <sys/types.h>   /* predefined types */
-#include <unistd.h>      /* include unix standard library */
-#include <arpa/inet.h>   /* IP addresses conversion utilities */
-#include <sys/socket.h>  /* socket library */
-#include <stdio.h>       /* include standard I/O library */
-#include <time.h>
 #define MAXLINE 80
 #define BACKLOG 10
 int main(int argc, char *argv[])
index e1fe9d6acb9418e4e01d23c4dfcc00171eb58530..ddb8e129b40d485b7a305ab50bc8842df9f29868 100644 (file)
  * Include needed headers
  */
 #include <stdlib.h>     /* standard library */
-#include <sys/types.h>   /* primitive system data types */
+//#include <sys/types.h>   /* primitive system data types */
 #include <unistd.h>      /* unix standard library */
 #include <arpa/inet.h>   /* IP addresses conversion utilities */
 #include <sys/socket.h>  /* socket constants, types and functions */
 #include <stdio.h>      /* standard I/O library */
 #include <string.h>     /* C strings library */
-#include <stdlib.h>     /* C standard library */
 
 #define MAXLINE 80
 /* Program begin */
index 5ae174c4f256c7c6bca1918c8305a0460915511b..cd0f7f65b5045143189cfc08a2f42cab9cb0f333 100644 (file)
@@ -31,7 +31,7 @@
 /* 
  * Include needed headers
  */
-#include <sys/types.h>   /* primitive system data types */
+//#include <sys/types.h>   /* primitive system data types */
 #include <unistd.h>      /* unix standard library */
 #include <arpa/inet.h>   /* IP addresses conversion utilities */
 #include <sys/socket.h>  /* socket constants, types and functions */
index 9771dad87d20228fae06439ffc9c2f5d89298b1a..b5b7748bcaa7860aee5b9851048fa191d38c525b 100644 (file)
@@ -30,7 +30,7 @@
 /* 
  * Include needed headers
  */
-#include <sys/types.h>   /* primitive system data types */
+//#include <sys/types.h>   /* primitive system data types */
 #include <unistd.h>      /* unix standard library */
 #include <arpa/inet.h>   /* IP addresses conversion utilities */
 #include <sys/socket.h>  /* socket constants, types and functions */
index 09759f41ce75011470ac177e0268aa7313c436ca..f15a3870814ecce8f28acc5790672c4e6e0d3e32 100644 (file)
@@ -1,4 +1,4 @@
-S%% tcpsock.tex
+%% tcpsock.tex
 %%
 %% Copyright (C) 2000-2016 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
@@ -1504,7 +1504,7 @@ Wed Apr 4 00:53:00 2001\r\n
 questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read}
 in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
   35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
-  36}) sullo standard output con l'uso di \func{fputs}.
+  36}) sullo \textit{standard output} con l'uso di \func{fputs}.
 
 Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
 potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
@@ -1526,7 +1526,7 @@ marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
 programma stesso.
 
 Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
-  fornito direttamente dal \textsl{superdemone} \cmd{inetd}, pertanto basta
+  fornito direttamente dal \textsl{superdemone} \cmd{xinetd}, pertanto basta
   assicurarsi che esso sia abilitato nel relativo file di configurazione.}
 possiamo verificare il funzionamento del nostro client, avremo allora:
 \begin{Console}
@@ -1567,8 +1567,8 @@ riga di comando.
 La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
 come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
 \struct{sockaddr\_in}.  Anche in questo caso (\texttt{\small 28}) si usa la
-porta standard del servizio daytime, ma come indirizzo IP si usa
-(\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
+porta standard del servizio \textit{daytime}, ma come indirizzo IP si usa
+(\texttt{\small 29}) il valore predefinito \const{INET\_ANY}, che corrisponde
 all'indirizzo generico.
 
 Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
@@ -1614,8 +1614,8 @@ parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
 di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
 \textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
 comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
-modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
-  ciclo principale.} per tener conto di quanto illustrato in
+modifiche (come una chiamata a \func{daemon} prima dell'inizio del ciclo
+principale) per tener conto di quanto illustrato in
 sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
 di gestione della terminazione del processo, dato che tutti i file descriptor
 vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
@@ -1661,8 +1661,8 @@ sorgenti degli altri esempi.
 Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
 fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
 la porta da cui il client effettua la connessione, che in un secondo tempo,
-(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
-output.
+(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo
+\textit{standard output}.
 
 Quando \func{accept} ritorna il server chiama la funzione \func{fork}
 (\texttt{\small 27--31}) per creare il processo figlio che effettuerà
@@ -1712,10 +1712,11 @@ caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
 estremamente breve e verrà senz'altro scritta in un singolo segmento.
 
 Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
-provvede anche (\texttt{\small 40--43}) a stampare sullo standard output
-l'indirizzo e la porta da cui il client ha effettuato la connessione, usando i
-valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
-opportune conversioni con \func{inet\_ntop} e \func{ntohs}.
+provvede anche (\texttt{\small 40--43}) a stampare sullo \textit{standard
+  output} l'indirizzo e la porta da cui il client ha effettuato la
+connessione, usando i valori contenuti nelle strutture restituite da
+\func{accept}, eseguendo le opportune conversioni con \func{inet\_ntop} e
+\func{ntohs}.
 
 Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
 non si sia gestita né la terminazione del processo né il suo uso come demone,
@@ -1726,7 +1727,6 @@ torneremo su questo più avanti quando tratteremo alcuni esempi di server più
 complessi.
 
 
-
 \section{Un esempio più completo: il servizio \textit{echo}}
 \label{sec:TCP_echo_application}
 
@@ -1750,7 +1750,6 @@ completa.
 \subsection{Il servizio \textit{echo}}
 \label{sec:TCP_echo}
 
-
 Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
 bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
 usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
@@ -1766,15 +1765,15 @@ direttamente dal superserver \cmd{inetd}, ed è definito
 dall'\href{http://www.ietf.org/rfc/rfc862.txt}{RFC~862}. Come dice il nome il
 servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
 ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
-il primo stabilisce che una volta stabilita la connessione ogni dato in
+qil primo stabilisce che una volta stabilita la connessione ogni dato in
 ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
 chiude la connessione. Al servizio è assegnata la porta riservata 7.
 
 Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
-caratteri dallo standard input e la scrive sul server. A sua volta il server
-leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
-compito del client leggere la risposta del server e stamparla sullo standard
-output.
+caratteri dallo \textit{standard input} e la scrive sul server. A sua volta il
+server leggerà la linea dalla connessione e la riscriverà immutata
+all'indietro. Sarà compito del client leggere la risposta del server e
+stamparla sullo \textit{standard output}.
 
 
 \subsection{Il client \textit{echo}: prima versione}
@@ -1787,7 +1786,7 @@ client per il servizio \textit{daytime} (vedi
 sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
 è sostanzialmente identica, a parte l'uso di una porta diversa.
 
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_echo_first.c}
@@ -1799,7 +1798,7 @@ sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
 
 Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
 riga di comando.  Una volta dichiarate le variabili, si prosegue
-(\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
+(\texttt{\small 10--13}) con la creazione del socket con l'usuale controllo
 degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
 dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
 \textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
@@ -1810,10 +1809,10 @@ sez.~\ref{sec:TCP_daytime_client}.
 Completata la connessione, per gestire il funzionamento del protocollo si usa
 la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
 fig.~\ref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
-comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
-scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
-risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche
-il programma termina.
+comunicazione, leggendo una riga alla volta dallo \textit{standard input}
+\file{stdin}, scrivendola sul socket e ristampando su \file{stdout} quanto
+ricevuto in risposta dal server. Al ritorno dalla funzione (\texttt{\small
+  30--31}) anche il programma termina.
 
 La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per
 gestire i dati inviati e letti sul socket.  La comunicazione viene gestita
@@ -1846,13 +1845,14 @@ scriverli su \file{stdout}.
   \label{fig:TCP_client_echo_sub}
 \end{figure}
 
-Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
-input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
-quanto spiegato in sez.~\ref{sec:file_line_io}) e la conseguente uscita dal
-ciclo; al che la subroutine ritorna ed il nostro programma client termina.
+Quando si concluderà l'invio di dati mandando un \textit{end-of-file} sullo
+\textit{standard input} si avrà il ritorno di \func{fgets} con un puntatore
+nullo (si riveda quanto spiegato in sez.~\ref{sec:file_line_io}) e la
+conseguente uscita dal ciclo; al che la subroutine ritorna ed il nostro
+programma client termina.
 
 Si può effettuare una verifica del funzionamento del client abilitando il
-servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
+servizio \textit{echo} nella configurazione di \cmd{xinetd} sulla propria
 macchina ed usandolo direttamente verso di esso in locale, vedremo in
 dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
 programma, usato però con la nostra versione del server \textit{echo}, che
@@ -1863,20 +1863,21 @@ illustriamo immediatamente.
 \label{sec:TCPsimp_server_main}
 
 La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
-è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
-per il client anche il server è stato diviso in un corpo principale,
-costituito dalla funzione \code{main}, che è molto simile a quello visto nel
-precedente esempio per il server del servizio \textit{daytime} di
+è riportata in fig.~\ref{fig:TCP_echo_server_first_code} e
+fig.~\ref{fig:TCP_echo_server_first_main}. Come abbiamo fatto per il client
+anche il server è stato diviso in un corpo principale, costituito dalla
+funzione \code{main}, che è molto simile a quello visto nel precedente esempio
+per il server del servizio \textit{daytime} di
 sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
 \code{ServEcho} che si cura della gestione del servizio.
 
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
-    \includecodesample{listati/TCP_echod_first.c}
+    \includecodesample{listati/TCP_echod_first_init.c}
   \end{minipage} 
   \normalsize
-  \caption{Codice del corpo principale della prima versione del server
+  \caption{Codice di inizializzatione della prima versione del server
     per il servizio \textit{echo}.}
   \label{fig:TCP_echo_server_first_code}
 \end{figure}
@@ -1917,21 +1918,35 @@ si apre il sistema di logging per la stampa degli errori, e poi
 (\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
 processo come demone.
 
-A questo punto il programma riprende di nuovo lo schema già visto usato dal
-server per il servizio \textit{daytime}, con l'unica differenza della chiamata
-alla funzione \code{PrintErr}, riportata in fig.~\ref{fig:TCP_PrintErr}, al
-posto di \func{perror} per la stampa degli errori. 
-
-Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si
-esegue indefinitamente il ciclo principale (\texttt{\small 42--59}).
-All'interno di questo si ricevono (\texttt{\small 43--47}) le connessioni,
-creando (\texttt{\small 48--51}) un processo figlio per ciascuna di esse.
-Quest'ultimo (\texttt{\small 52--56}), chiuso (\texttt{\small 53}) il
-\textit{listening socket}, esegue (\texttt{\small 54}) la funzione di gestione
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{\codesamplewidth}
+    \includecodesample{listati/TCP_echod_first_main.c}
+  \end{minipage} 
+  \normalsize
+  \caption{Codice di inizializzatione della prima versione del server
+    per il servizio \textit{echo}.}
+  \label{fig:TCP_echo_server_first_main}
+\end{figure}
+
+A questo punto il programma prosegue nel ciclo principale, illustrato in
+fig.~\ref{fig:TCP_echo_server_first_main}, usando lo schema già visto in
+precedenza per server per il servizio \textit{daytime}, con l'unica differenza
+della chiamata alla funzione \code{PrintErr}, riportata in
+fig.~\ref{fig:TCP_PrintErr}, al posto di \func{perror} per la stampa degli
+errori.
+
+Si inizia con il porre (\texttt{\small 3--6}) in ascolto il socket, e poi si
+esegue indefinitamente il ciclo principale (\texttt{\small 7--26}).
+All'interno di questo si ricevono (\texttt{\small 9--12}) le connessioni,
+creando (\texttt{\small 13--16}) un processo figlio per ciascuna di esse.
+Quest'ultimo (\texttt{\small 17--21}), chiuso (\texttt{\small 18}) il
+\textit{listening socket}, esegue (\texttt{\small 19}) la funzione di gestione
 del servizio \code{ServEcho}, ed al ritorno di questa esce (\texttt{\small
-  55}).
+  20}).
 
-Il padre invece si limita (\texttt{\small 57}) a chiudere il \textit{connected
+Il padre invece si limita (\texttt{\small 22}) a chiudere il \textit{connected
   socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
 questo modo si ha un server concorrente. La terminazione del padre non è
 gestita esplicitamente, e deve essere effettuata inviando un segnale al
@@ -1944,39 +1959,42 @@ sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
 come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
 in fig.~\ref{fig:TCP_PrintErr}.
 
-In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
-(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
-  3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
-messaggio di errore fornito come argomento sui log di sistema. Se invece si è
-in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
-(\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
-standard error.
-
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/PrintErr.c}
   \end{minipage} 
   \normalsize
-  \caption{Codice della funzione \code{PrintErr} per la
-    generalizzazione della stampa degli errori sullo standard input o
-    attraverso il \texttt{syslog}.}
+  \caption{Codice della funzione \code{PrintErr} per la generalizzazione della
+    stampa degli errori sullo \textit{standard input} o attraverso il
+    \texttt{syslog}.}
   \label{fig:TCP_PrintErr}
 \end{figure}
 
+
+In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
+(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
+  3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
+messaggio di errore fornito come argomento sui log di sistema. Se invece si è
+in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
+(\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
+\textit{standard error}.
+
 La gestione del servizio \textit{echo} viene effettuata interamente nella
 funzione \code{ServEcho}, il cui codice è mostrato in
 fig.~\ref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
 di un ciclo (\texttt{\small 6--13}).  I dati inviati dal client vengono letti
 (\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
 controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
-in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
-funzione \func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_code}) che
-si incarica di tenere conto automaticamente della possibilità che non tutti i
+in arrivo. 
+
+La riscrittura (\texttt{\small 7}) viene invece gestita dalla funzione
+\func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_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}[!htbp
+\begin{figure}[!htb] 
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ServEcho_first.c}
@@ -1990,29 +2008,29 @@ dati di cui è richiesta la scrittura vengano trasmessi con una singola
 In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
 valore nullo in caso di successo) si provvede (\texttt{\small 8--10}) a
 stampare il relativo messaggio con \func{PrintErr}.  Quando il client chiude
-la connessione il ricevimento del FIN fa ritornare la \func{read} con un
-numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il ritorno
-(\texttt{\small 12}) della funzione, che a sua volta causa la terminazione del
-processo figlio.
+la connessione il ricevimento del segmento FIN fa ritornare la \func{read} con
+un numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il
+ritorno (\texttt{\small 12}) della funzione, che a sua volta causa la
+terminazione del processo figlio.
 
 
-\subsection{L'avvio e il funzionamento normale}
+\subsection{L'avvio e il funzionamento ordinario}
 \label{sec:TCP_echo_startup}
 
 Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
 di considerare in dettaglio le varie problematiche che si possono incontrare
 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
-necessarie per essere in grado di scrivere applicazioni robuste, in grado di
-gestire anche i casi limite.
-
-Il primo passo è compilare e lanciare il server (da root, per poter usare la
-porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
-la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
-si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
-stato con \cmd{netstat}:
+modalità di funzionamento ordinarie, 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 necessarie per essere in grado di scrivere applicazioni robuste,
+in grado di gestire anche i casi limite.
+
+Il primo passo è compilare e lanciare il server (usando l'utente di
+amministrazione, per poter usare la porta 7 che è riservata). All'avvio esso
+eseguirà l'apertura passiva con la sequenza delle chiamate a \func{socket},
+\func{bind}, \func{listen} e poi si bloccherà nella \func{accept}. A questo
+punto si potrà controllarne lo stato con \cmd{netstat}:
 \begin{Console}
 [piccardi@roke piccardi]$ \textbf{netstat -at}
 Active Internet connections (servers and established)
@@ -2067,12 +2085,12 @@ tre processi, tutti in stato di \textit{sleep} (vedi
 tab.~\ref{tab:proc_proc_states}).
 
 Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
-niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
-in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
-\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
-poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
-a sua volta sarà inviato sullo standard output, che nel caso ne provoca
-l'immediata stampa a video.
+niente fintanto che non si preme il tasto di a capo (si ricordi quanto detto
+in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale).  Solo
+allora \func{fgets} ritornerà ed il client scriverà quanto immesso dal
+terminale sul socket, per poi passare a rileggere quanto gli viene inviato
+all'indietro dal server, che a sua volta sarà inviato sullo \textit{standard
+  output}, che nel caso ne provoca l'immediata stampa a video.
 
 
 \subsection{La conclusione normale}
@@ -2224,7 +2242,6 @@ su qualunque sistema.  Inoltre in certi casi,\footnote{Stevens in \cite{UNP1}
   cosa che invece nel caso di Linux viene sempre fatta.} anche quando questa è
 presente, non è detto possa essere usata con \func{accept}.
 
-
 La portabilità nella gestione dei segnali però viene al costo di una
 riscrittura parziale del server, la nuova versione di questo, in cui si sono
 introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
@@ -2250,7 +2267,7 @@ fig.~\ref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
 gestione di tutte queste opzioni, che può essere trovata nel sorgente del
 programma.
 
-\begin{figure}[!htbp]
+\begin{figure}[!htb ]
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/TCP_echod_second.c}
@@ -2302,11 +2319,22 @@ qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
 altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
 altrimenti il programma prosegue.
 
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{\codesamplewidth}
+    \includecodesample{listati/ServEcho_second.c}
+  \end{minipage} 
+  \normalsize
+  \caption{Codice della seconda versione della funzione \code{ServEcho} per la
+    gestione del servizio \textit{echo}.}
+  \label{fig:TCP_ServEcho_second}
+\end{figure}
+
 Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
 (\texttt{\small 32--40}) di aiuto per il debug del programma, che eseguita con
 un controllo (\texttt{\small 33}) sul valore della variabile \var{debugging}
 impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
-preimpostato, non accade nulla. altrimenti (\texttt{\small 33}) l'indirizzo
+preimpostato, non accade nulla, altrimenti (\texttt{\small 33}) l'indirizzo
 ricevuto da \var{accept} viene convertito in una stringa che poi
 (\texttt{\small 34--39}) viene opportunamente stampata o sullo schermo o nei
 log.
@@ -2316,18 +2344,7 @@ sia per tenere conto della nuova funzionalità di debugging, che per effettuare
 un controllo in caso di errore; il codice della nuova versione è mostrato in
 fig.~\ref{fig:TCP_ServEcho_second}.
 
-\begin{figure}[!htbp] 
-  \footnotesize \centering
-  \begin{minipage}[c]{\codesamplewidth}
-    \includecodesample{listati/ServEcho_second.c}
-  \end{minipage} 
-  \normalsize
-  \caption{Codice della seconda versione della funzione \code{ServEcho} per la
-    gestione del servizio \textit{echo}.}
-  \label{fig:TCP_ServEcho_second}
-\end{figure}
-
-Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
+ Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
 questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
 ritorno di \func{read} per rilevare un eventuale errore, in modo da stampare
 (\texttt{\small 8}) un messaggio di errore e ritornare (\texttt{\small 9})
@@ -2360,8 +2377,8 @@ qualche errore sulla rete, della connessione effettuata da un client. Come
 accennato in sez.~\ref{sec:TCP_func_accept} la funzione \func{accept} riporta
 tutti gli eventuali errori di rete pendenti su una connessione sul
 \textit{connected socket}. Di norma questo non è un problema, in quanto non
-appena completata la connessione, \func{accept} ritorna e l'errore sarà
-rilevato in seguito, dal processo che gestisce la connessione, alla prima
+appena completata la connessione, \func{accept} ritorna, e l'errore sarà
+rilevato in seguito dal processo che gestisce la connessione, alla prima
 chiamata di una funzione che opera sul socket.
 
 È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
@@ -2387,15 +2404,15 @@ analoga a quella illustrata in fig.~\ref{fig:TCP_early_abort}, in cui la
 connessione viene stabilita, ma subito dopo si ha una condizione di errore che
 la chiude prima che essa sia stata accettata dal programma.
 
-Questo significa che, oltre alla interruzione da parte di un segnale, che
+Questo significa che oltre alla interruzione da parte di un segnale, che
 abbiamo trattato in sez.~\ref{sec:TCP_child_hand} nel caso particolare di
 \signal{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
-\func{accept}, che come nel caso precedente, necessitano semplicemente la
-ripetizione della chiamata senza che si debba uscire dal programma. In questo
-caso anche la versione modificata del nostro server non sarebbe adatta, in
-quanto uno di questi errori causerebbe la terminazione dello stesso. In Linux
-i possibili errori di rete non fatali, riportati sul socket connesso al
-ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
+\func{accept}; questi, come nel caso precedente, necessitano semplicemente la
+ripetizione della chiamata senza uscire dal programma. In questo caso anche la
+versione modificata del nostro server non sarebbe adatta, in quanto uno di
+questi errori causerebbe la terminazione dello stesso. In Linux i possibili
+errori di rete non fatali, riportati sul socket connesso al ritorno di
+\func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
 \errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
 \errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
 
@@ -2406,13 +2423,13 @@ demone, in modo da poter avere il tempo per lanciare e terminare una
 connessione usando il programma client. In tal caso infatti, alla terminazione
 del client, il socket associato alla connessione viene semplicemente chiuso,
 attraverso la sequenza vista in sez.~\ref{sec:TCP_conn_term}, per cui la
-\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
-al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
-modifichi il client per fargli gestire l'invio di un segmento di RST alla
-chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
-sez.~\ref{sec:sock_options_main}), non si ha nessun errore al ritorno di
-\func{accept}, quanto un errore di \errcode{ECONNRESET} al primo tentativo di
-accesso al socket.
+\func{accept} ritornerà senza errori, e si avrà semplicemente un
+\textit{end-of-file} al primo accesso al socket. Nel caso di Linux inoltre,
+anche qualora si modifichi il client per fargli gestire l'invio di un segmento
+RST alla chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
+sez.~\ref{sec:sock_options_main}), non si ha comunque nessun errore al ritorno
+di \func{accept}, quanto un errore di \errcode{ECONNRESET} al primo tentativo
+di accesso al socket.
 
 
 
@@ -2468,10 +2485,10 @@ formato configurabile in maniera molto precisa).
 
 Lanciando il comando prima di ripetere la sessione di lavoro mostrata
 nell'esempio precedente potremo allora catturare tutti pacchetti scambiati fra
-il client ed il server; i risultati\footnote{in realtà si è ridotta la
-  lunghezza dell'output rispetto al reale tagliando alcuni dati non necessari
-  alla comprensione del flusso.} prodotti in questa occasione da \cmd{tcpdump}
-sono allora i seguenti:
+il client ed il server; i risultati (in realtà si è ridotta la lunghezza
+dell'output rispetto al reale tagliando alcuni dati non necessari alla
+comprensione del flusso) prodotti in questa occasione da \cmd{tcpdump} sono
+allora i seguenti:
 \begin{Console}
 [root@gont gapil]# \textbf{tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t}
 tcpdump: listening on eth0
@@ -2613,10 +2630,11 @@ la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
 \end{figure}
 
 Come si può vedere in questo caso si controlla il valore di ritorno di tutte
-le funzioni, ed inoltre si verifica la presenza di un eventuale end of file in
-caso di lettura. Con questa modifica il nostro client echo diventa in grado di
-accorgersi della chiusura del socket da parte del server, per cui ripetendo la
-sequenza di operazioni precedenti stavolta otterremo che:
+le funzioni, ed inoltre si verifica la presenza di un eventuale
+\textit{end-of-file} in caso di lettura. Con questa modifica il nostro client
+\cmd{echo} diventa in grado di accorgersi della chiusura del socket da parte
+del server, per cui ripetendo la sequenza di operazioni precedenti stavolta
+otterremo che:
 \begin{Console}
 [piccardi@gont sources]$ \textbf{./echo 192.168.1.141}
 Prima riga
@@ -2636,9 +2654,9 @@ relativo al nostro client, e che cioè esso non è in grado di accorgersi di
 nulla fintanto che è bloccato nella lettura del terminale fatta con
 \func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
 avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
-fare con la necessità di lavorare con più descrittori, nel qual caso diventa
-si pone la questione di come fare a non restare bloccati su un socket quando
-altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
+fare con la necessità di lavorare con più descrittori, nel qual caso si pone
+la questione di come fare a non restare bloccati su un socket quando altri
+potrebbero essere liberi. Vedremo come affrontare questa problematica in
 sez.~\ref{sec:TCP_sock_multiplexing}.
  
 
@@ -2649,12 +2667,11 @@ La terminazione del server è solo uno dei possibili scenari di terminazione
 della connessione, un altro caso è ad esempio quello in cui si ha un crollo
 della rete, cosa che potremo simulare facilmente staccando il cavo di rete.
 Un'altra condizione è quella di un blocco della macchina completo della su cui
-gira il server che deve essere riavviata, cosa che potremo simulare sia
-premendo il bottone di reset,\footnote{un normale shutdown non va bene; in tal
-  caso infatti il sistema provvede a terminare tutti i processi, per cui la
-  situazione sarebbe sostanzialmente identica alla precedente.} che, in
-maniera più gentile, riavviando la macchina dopo aver interrotto la
-connessione di rete.
+gira il server che deve essere riavviata, cosa che potremo simulare eseguendo
+un reset fisico,\footnote{un normale shutdown non va bene; in tal caso infatti
+  il sistema provvede a terminare tutti i processi, per cui la situazione
+  sarebbe sostanzialmente identica alla precedente.} che, in maniera più
+gentile, riavviando la macchina dopo aver interrotto la connessione di rete.
 
 Cominciamo ad analizzare il primo caso, il crollo della rete. Ripetiamo la
 nostra sessione di lavoro precedente, lanciamo il client, scriviamo una prima
@@ -2973,22 +2990,22 @@ Abbiamo incontrato la problematica tipica che conduce all'uso dell'I/O
 multiplexing nella nostra analisi degli errori in
 sez.~\ref{sec:TCP_conn_early_abort}, quando il nostro client non era in grado
 di rendersi conto di errori sulla connessione essendo impegnato nella attesa
-di dati in ingresso dallo standard input.
+di dati in ingresso dallo \textit{standard input}.
 
 In questo caso il problema è quello di dover tenere sotto controllo due
-diversi file descriptor, lo standard input, da cui viene letto il testo che
-vogliamo inviare al server, e il socket connesso con il server su cui detto
-testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
-dell'I/O multiplexing consente di tenere sotto controllo entrambi, senza
-restare bloccati.
+diversi file descriptor, lo \textit{standard input}, da cui viene letto il
+testo che vogliamo inviare al server, e il socket connesso con il server su
+cui detto testo sarà scritto e dal quale poi si vorrà ricevere la
+risposta. L'uso dell'I/O multiplexing consente di tenere sotto controllo
+entrambi, senza restare bloccati.
 
 Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
-standard input in caso di errori sulla connessione o chiusura della stessa da
-parte del server. Entrambi questi casi possono essere rilevati usando
-\func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select}, mettendo
-sotto osservazione i file descriptor per la condizione di essere pronti in
-lettura: sia infatti che si ricevano dati, che la connessione sia chiusa
-regolarmente (con la ricezione di un segmento FIN) che si riceva una
+\textit{standard input} in caso di errori sulla connessione o chiusura della
+stessa da parte del server. Entrambi questi casi possono essere rilevati
+usando \func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select},
+mettendo sotto osservazione i file descriptor per la condizione di essere
+pronti in lettura: sia infatti che si ricevano dati, che la connessione sia
+chiusa regolarmente (con la ricezione di un segmento FIN) che si riceva una
 condizione di errore (con un segmento RST) il socket connesso sarà pronto in
 lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
 nostri scopi).
@@ -3024,11 +3041,11 @@ preprocessore di varia utilità.
 La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
 viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
 (\texttt{\small 11--12}) il \textit{file descriptor set}, impostando i valori
-per il file descriptor associato al socket \var{socket} e per lo standard
-input (il cui valore si recupera con la funzione \func{fileno}). Questo è
-necessario in quanto la successiva (\texttt{\small 13}) chiamata a
-\func{select} comporta una modifica dei due bit relativi, che quindi devono
-essere reimpostati all'inizio di ogni ciclo.
+per il file descriptor associato al socket \var{socket} e per lo
+\textit{standard input} (il cui valore si recupera con la funzione
+\func{fileno}). Questo è necessario in quanto la successiva (\texttt{\small
+  13}) chiamata a \func{select} comporta una modifica dei due bit relativi,
+che quindi devono essere reimpostati all'inizio di ogni ciclo.
 
 Si noti come la chiamata a \func{select} venga eseguita usando come primo
 argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
@@ -3039,35 +3056,36 @@ valore di timeout.
 
 Al ritorno di \func{select} si provvede a controllare quale dei due file
 descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
-con il file descriptor associato allo standard input. In caso di attività
-(quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
-(\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati presenti;
-se non ve ne sono (e la funzione restituisce pertanto un puntatore nullo) si
-ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
-chiuso lo standard input e quindi concluso l'utilizzo del client; altrimenti
-(\texttt{\small 18--22}) si scrivono i dati appena letti sul socket,
-prevedendo una uscita immediata in caso di errore di scrittura.
-
-Controllato lo standard input si passa a controllare (\texttt{\small 25--40})
-il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
-una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
-(\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
-immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
-il server ha chiuso la connessione, e di nuovo si esce con stampando prima un
-messaggio di avviso, altrimenti (\texttt{\small 35--39}) si effettua la
-terminazione della stringa e la si stampa a sullo standard output (uscendo in
-caso di errore), per ripetere il ciclo da capo.
+con il file descriptor associato allo \textit{standard input}. In caso di
+attività (quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si
+esegue (\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati
+presenti; se non ve ne sono (e la funzione restituisce pertanto un puntatore
+nullo) si ritorna immediatamente (\texttt{\small 16}) dato che questo
+significa che si è chiuso lo \textit{standard input} e quindi concluso l'utilizzo del
+client; altrimenti (\texttt{\small 18--22}) si scrivono i dati appena letti
+sul socket, prevedendo una uscita immediata in caso di errore di scrittura.
+
+Controllato lo \textit{standard input} si passa a controllare (\texttt{\small
+  25--40}) il socket connesso, in caso di attività (\texttt{\small 26}) si
+esegue subito una \func{read} di cui si controlla il valore di ritorno; se
+questo è negativo (\texttt{\small 27--30}) si è avuto un errore e pertanto si
+esce immediatamente segnalandolo, se è nullo (\texttt{\small 31--34})
+significa che il server ha chiuso la connessione, e di nuovo si esce con
+stampando prima un messaggio di avviso, altrimenti (\texttt{\small 35--39}) si
+effettua la terminazione della stringa e la si stampa a sullo \textit{standard
+  output} (uscendo in caso di errore), per ripetere il ciclo da capo.
 
 Con questo meccanismo il programma invece di essere bloccato in lettura sullo
-standard input resta bloccato sulla \func{select}, che ritorna soltanto quando
-viene rilevata attività su uno dei due file descriptor posti sotto controllo.
-Questo di norma avviene solo quando si è scritto qualcosa sullo standard
-input, o quando si riceve dal socket la risposta a quanto si era appena
-scritto. Ma adesso il client diventa capace di accorgersi immediatamente della
-terminazione del server; in tal caso infatti il server chiuderà il socket
-connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
-illustrato in sez.~\ref{sec:TCP_sock_select}) segnalando una condizione di end
-of file, per cui il nostro client potrà uscire immediatamente.
+\textit{standard input} resta bloccato sulla \func{select}, che ritorna
+soltanto quando viene rilevata attività su uno dei due file descriptor posti
+sotto controllo.  Questo di norma avviene solo quando si è scritto qualcosa
+sullo \textit{standard input}, o quando si riceve dal socket la risposta a quanto si
+era appena scritto. Ma adesso il client diventa capace di accorgersi
+immediatamente della terminazione del server; in tal caso infatti il server
+chiuderà il socket connesso, ed alla ricezione del FIN la funzione
+\func{select} ritornerà (come illustrato in sez.~\ref{sec:TCP_sock_select})
+segnalando una condizione di end of file, per cui il nostro client potrà
+uscire immediatamente.
 
 Riprendiamo la situazione affrontata in sez.~\ref{sec:TCP_server_crash},
 terminando il server durante una connessione, in questo caso quello che
@@ -3236,8 +3254,8 @@ questi potrà ancora inviarci. Questo è ad esempio l'uso che ci serve per
 rendere finalmente completo il nostro esempio sul servizio \textit{echo}. Il
 nostro client infatti presenta ancora un problema, che nell'uso che finora ne
 abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena
-usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo standard
-input e standard output. Così se eseguiamo:
+usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo
+\textit{standard input} e \textit{standard output}. Così se eseguiamo:
 \begin{Console}
 [piccardi@gont sources]$ \textbf{./echo 192.168.1.1 < ../fileadv.tex  > copia}
 \end{Console}
@@ -3245,16 +3263,16 @@ input e standard output. Così se eseguiamo:
 vedremo che il file \texttt{copia} risulta mancare della parte finale.
 
 Per capire cosa avviene in questo caso occorre tenere presente come avviene la
-comunicazione via rete; quando redirigiamo lo standard input il nostro client
-inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
-dimensione massima pari a \texttt{MAXLINE} per poi scriverlo, alla massima
-velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
-una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
-vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
-di processo, questo tempo è quello impiegato nella trasmissione via rete, che
-viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time~(RTT)}
-\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
-\cmd{ping}.
+comunicazione via rete; quando redirigiamo lo \textit{standard input} il
+nostro client inizierà a leggere il contenuto del file \texttt{../fileadv.tex}
+a blocchi di dimensione massima pari a \texttt{MAXLINE} per poi scriverlo,
+alla massima velocità consentitagli dalla rete, sul socket. Dato che la
+connessione è con una macchina remota occorre un certo tempo perché i
+pacchetti vi arrivino, vengano processati, e poi tornino
+indietro. Considerando trascurabile il tempo di processo, questo tempo è
+quello impiegato nella trasmissione via rete, che viene detto RTT (dalla
+denominazione inglese \itindex{Round~Trip~Time~(RTT)} \textit{Round Trip
+  Time}) ed è quello che viene stimato con l'uso del comando \cmd{ping}.
 
 A questo punto, se torniamo al codice mostrato in
 fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
@@ -3306,10 +3324,11 @@ del file in ingresso.
 
 La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
 subordinato ad un valore nullo di \var{eof} l'impostazione del file descriptor
-set per l'osservazione dello standard input. Se infatti il valore di \var{eof}
-è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
-pertanto inutile continuare a tenere sotto controllo lo standard input nella
-successiva (\texttt{\small 16}) chiamata a \func{select}.
+set per l'osservazione dello \textit{standard input}. Se infatti il valore di
+\var{eof} è non nullo significa che si è già raggiunta la fine del file in
+ingresso ed è pertanto inutile continuare a tenere sotto controllo lo
+\textit{standard input} nella successiva (\texttt{\small 16}) chiamata a
+\func{select}.
 
 Le maggiori modifiche rispetto alla precedente versione sono invece nella
 gestione (\texttt{\small 18--22}) del caso in cui la lettura con \func{fgets}
@@ -3318,15 +3337,15 @@ precedente versione causava l'immediato ritorno della funzione; in questo caso
 prima (\texttt{\small 19}) si imposta opportunamente \var{eof} ad un valore
 non nullo, dopo di che (\texttt{\small 20}) si effettua la chiusura del lato
 in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si
-usa la macro \macro{FD\_CLR} per togliere lo standard input dal \textit{file
-  descriptor set}.
+usa la macro \macro{FD\_CLR} per togliere lo \textit{standard input} dal
+\textit{file descriptor set}.
 
 In questo modo anche se la lettura del file in ingresso è conclusa, la
 funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
 ad eseguirlo ripetendo la chiamata a \func{select} per tenere sotto controllo
 soltanto il socket connesso, dal quale possono arrivare altri dati, che
 saranno letti (\texttt{\small 31}), ed opportunamente trascritti
-(\texttt{\small 44--48}) sullo standard output.
+(\texttt{\small 44--48}) sullo \textit{standard output}.
 
 Il ritorno della funzione, e la conseguente terminazione normale del client,
 viene invece adesso gestito all'interno (\texttt{\small 30--49}) della lettura
@@ -3612,9 +3631,10 @@ negativo del campo \var{fd} ma predisponendo (\texttt{\small 6}) il campo
 \var{events} per l'osservazione dei dati normali con \const{POLLRDNORM}.
 Infine (\texttt{\small 8}) si attiva l'osservazione del socket in ascolto
 inizializzando la corrispondente struttura. Questo metodo comporta, in
-modalità interattiva, lo spreco di tre strutture (quelle relative a standard
-input, output ed error) che non vengono mai utilizzate in quanto la prima è
-sempre quella relativa al socket in ascolto.
+modalità interattiva, lo spreco di tre strutture (quelle relative a
+\textit{standard input}, \textit{standard output} e \textit{standard error})
+che non vengono mai utilizzate in quanto la prima è sempre quella relativa al
+socket in ascolto.
 
 Una volta completata l'inizializzazione tutto il lavoro viene svolto
 all'interno del ciclo principale \texttt{\small 10--55}) che ha una struttura