Iniziato capitolo sul server echo, modificato Makefile secondo i suggerimenti

di L. Fasolo per fargli generare meglio le figure

diff --git a/Makefile b/Makefile
index f32575bc2b92b0073b2eef4454df5ae64b44dd5f..3ce18629b987c83fa981776a006251a867a8363c 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
 html:
-       latex2html main.tex
+       latex2html -local_icons main.tex
 
 dvi: 
        latex main.tex

diff --git a/elemtcp.tex b/elemtcp.tex
index 50d8994d103814fbee5ea5cbb21a783de907cfa8..f8bc164e6c60eaaf500639e27ee82a882b710e95 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -8,10 +8,6 @@ nei due esempi elementari forniti in precedenza (vedi
 descrizione delle principali caratteristiche del funzionamento di una
 connessione TCP.
 
-Infine riscriveremo il precedente esempio elementare di server
-\texttt{daytime} in una forma appena più evoluta (come server concorrente) e
-con alcune caratteristiche aggiuntive che mettano in luce quanto andremo ad
-illustrare.
 
 \section{Il funzionamento di una connessione TCP}
 \label{sec:TCPel_connession}
@@ -1243,27 +1239,32 @@ quella connessione.
 La funzione \texttt{getpeername} si usa tutte le volte che si vuole avere
 l'indirizzo remoto di un socket. 
 
-Benché nell'esempio precedente si siano usati i valori di ritorno di
-\texttt{accept} per ottenere l'indirizzo del client remoto, in generale questo
-non è possibile. In particolare questo avviene quando il server invece di far
-gestire la connessione direttamente al figlio, come nell'esempio precedente,
-lancia un opportuno programma per ciascuna connessione usando \texttt{exec}
-(come ad esempio fa il \textsl{super-server} \texttt{inetd} che gestisce tutta
-una serie di servizi lanciando per ogni connessione l'opportuno server).
+Ci si può chiedere a cosa serva questa funzione dato che dal lato client
+l'indirizzo remoto è sempre noto quando si esegue la \texttt{connect} mentre
+dal lato server si possono usare, come si è fatto nell'esempio precedente, i
+valori di ritorno di \texttt{accept}.
+
+In generale però questa ultima possibilità è sempre possibile. In particolare
+questo avviene quando il server invece di far gestire la connessione
+direttamente a un processo figlio, come nell'esempio precedente, lancia un
+opportuno programma per ciascuna connessione usando \texttt{exec} (questa ad
+esempio è la modailità con cui opera il \textsl{super-server} \texttt{inetd}
+che gestisce tutta una serie di servizi lanciando per ogni connessione
+l'opportuno server).
 
 In questo caso benché il processo figlio abbia una immagine della memoria che
 è copia di quella del processo padre (e contiene quindi anche la struttura
-ritornata da \texttt{accept}) all'esecuzione di \texttt{exec} viene caricata
+ritornata da \texttt{accept}), all'esecuzione di \texttt{exec} viene caricata
 in memoria l'immagine del programma eseguito che a questo punto perde ogni
-riferimento; ma il socket descriptor resta aperto. Allora se una opportuna
+riferimento. Il socket descriptor però resta aperto. Allora se una opportuna
 convenzione è seguita per rendere noto al programma eseguito qual'è il socket
 connesso (\texttt{inetd} ad esempio fa sempre in modo che i file descriptor 0,
-1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare
+1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione
 \texttt{getpeername} per determinare l'indirizzo remoto del client.
 
-Infine è da chiarire che come per \texttt{accept} il terzo parametro che è
-specificato dallo standard POSIX 1003.1g come di tipo \texttt{socklen\_t *} in
-realtà deve sempre corrispondere ad un \texttt{int *} come prima dello
-standard perché tutte le implementazioni dei socket BSD fanno questa
-assunzione.
+Infine è da chiarire (si legga la man page) che come per \texttt{accept} il
+terzo parametro che è specificato dallo standard POSIX 1003.1g come di tipo
+\texttt{socklen\_t *} in realtà deve sempre corrispondere ad un \texttt{int *}
+come prima dello standard perché tutte le implementazioni dei socket BSD fanno
+questa assunzione.
 

diff --git a/main.tex b/main.tex
index 0a2977c723e8a5229fd698ab31934b40e2c140b8..e2b93adda01d63d6238f5d0b2576c107d31d3cfb 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -107,6 +107,7 @@
 \include{network}
 \include{socket}
 \include{elemtcp}
+\include{simpltcp}
 \include{app_a}
 \include{app_b}
 \include{fdl}

diff --git a/simpltcp.tex b/simpltcp.tex
new file mode 100644 (file)
index 0000000..de49446
--- /dev/null
+++ b/simpltcp.tex
@@ -0,0 +1,35 @@
+\chapter{Un esempio completo di client/server TCP}
+\label{cha:simple_TCP_sock}
+
+In questo capitolo riprenderemo le funzioni trattate nel precedente, usandole
+per scrivere una prima applicazione client/server che usi i socket TCP per una
+comunicazione in entrambe le direzioni. 
+
+L'applicazione sarà una implementazione elementare, ma completa, del servizio
+\texttt{echo}. Si è scelto di usare questo servizio, seguendo lo Stevens, in
+quanto esso costituisce il prototipo ideale di una generica applicazione di
+rete; pertanto attraverso questo esempio potremo illustrare i fondamenti con i
+quali si può costruire una qualunque applicazione di rete. 
+
+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.
+
+
+\section{Il servizio \texttt{echo}}
+\label{sec:TCPsimp_echo}
+
+Il servizio \texttt{echo} è uno dei servizi standard solitamente provvisti
+direttamente dal superserver \texttt{inetd}, definito dall'RFC~862. Come dice
+il nome il servizio deve semplicemente rimandare indietro i dati che gli
+vengono inviati; l'RFC specifica che per il TCP una volta stabilita la
+connessione ogni dato in ingresso deve essere rimandato in uscita, fintanto
+che il chiamante non ha chiude la connessione; il servizio opera sulla porta
+TCP numero 7.
+
+Nel nostro caso l'esempio sarà strutturato scrivendo un client che legge una
+linea dallo standard input e la scrive sul server, il server leggerà una linea
+dalla connessione e la riscriverà all'indietro; sarà compito del client
+leggere la risposta del server e stamparla sullo standard output.
+