X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=elemtcp.tex;h=f8bc164e6c60eaaf500639e27ee82a882b710e95;hp=50d8994d103814fbee5ea5cbb21a783de907cfa8;hb=091527e47fd90180e50ceee95a72340f990d999f;hpb=66765a9be9a61085dd00abd92d99a24b23dc844b

diff --git a/elemtcp.tex b/elemtcp.tex
index 50d8994..f8bc164 100644
--- 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.