X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=simpltcp.tex;h=c119df0a2bba2035a61d1a768c3ce586d26133de;hp=6183212cc55ec8395cc35fa5068481e33424ffb4;hb=9aeb46d93d970f26f1939d3853e4a9e62b2eb5b9;hpb=b3b4f26462b7f1898aee125226952995270167d7

diff --git a/simpltcp.tex b/simpltcp.tex
index 6183212..c119df0 100644
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -17,7 +17,7 @@ durante l'impiego di una applicazione di rete.
 L'applicazione scelta come esempio sarà una implementazione elementare, ma
 completa, del servizio \texttt{echo}. Il servizio \texttt{echo} è uno dei
 servizi standard solitamente provvisti direttamente dal superserver
-\texttt{inetd}, ed è definito dall'RFC~862. Come dice il nome il servizio deve
+\cmd{inetd}, ed è definito dall'RFC~862. Come dice il nome il servizio deve
 rimandare indietro sulla connessione i dati che gli vengono inviati; l'RFC
 descrive le specifiche sia per TCP che UDP, e per il primo stabilisce che una
 volta stabilita la connessione ogni dato in ingresso deve essere rimandato in
@@ -44,7 +44,7 @@ una implementazione completa.
 \label{sec:TCPsimp_server_main}
 
 La prima versione del server, \file{ElemEchoTCPServer.c}, si compone di un
-corpo principale, costituito dalla funzione \func{main}.  Questa si incarica
+corpo principale, costituito dalla funzione \code{main}.  Questa si incarica
 di creare il socket, metterlo in ascolto di connessioni in arrivo e creare un
 processo figlio a cui delegare la gestione di ciascuna connessione.  Questa
 parte, riportata in \nfig, è analoga a quella vista nel precedente esempio
@@ -106,7 +106,7 @@ int main(int argc, char *argv[])
     exit(0);
 }
   \end{lstlisting}
-  \caption{Codice della funzione \texttt{main} della prima versione del server
+  \caption{Codice della funzione \code{main} della prima versione del server
     per il servizio \texttt{echo}.}
   \label{fig:TCPsimpl_serv_code}
 \end{figure}
@@ -116,15 +116,15 @@ quella dell'esempio citato, ed ad esso si applicano le considerazioni fatte in
 \secref{sec:TCPel_cunc_daytime}. Le uniche differenze rispetto all'esempio in
 \figref{fig:TCPel_serv_code} sono che in questo caso per il socket in
 ascolto viene usata la porta 7 e tutta la gestione della comunicazione è
-delegata alla funzione \func{ServEcho}.
+delegata alla funzione \code{ServEcho}.
 %  Per ogni connessione viene creato un
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 
-Il codice della funzione \func{ServEcho} è invece mostrata in \nfig, la
+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
-\texttt{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura
+\func{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura
 viene invece gestita dalla funzione \func{SockWrite} (descritta a suo tempo
 in \figref{fig:sock_SockWrite_code}) che si incarica di tenere conto
 automaticamente della possibilità che non tutti i dati di cui è richiesta la
@@ -145,7 +145,7 @@ void ServEcho(int sockfd) {
     return;
 }
   \end{lstlisting}
-  \caption{Codice della prima versione della funzione \texttt{ServEcho} per la
+  \caption{Codice della prima versione della funzione \code{ServEcho} per la
     gestione del servizio \texttt{echo}.}
   \label{fig:TCPsimpl_server_elem_sub}
 \end{figure}
@@ -204,14 +204,14 @@ int main(int argc, char *argv[])
   \label{fig:TCPsimpl_client_elem}
 \end{figure}
 
-La funzione \func{main} si occupa della creazione del socket e della
+La funzione \code{main} si occupa della creazione del socket e della
 connessione (linee \texttt{\small 10--27}) secondo la stessa modalità spiegata
 in \secref{sec:net_cli_sample}, il client si connette sulla porta 7
 all'indirizzo specificato dalla linea di comando (a cui si è aggiunta una
 elementare gestione delle opzioni non riportata in figura).
 
 Completata la connessione (quando la funzione \func{connect} ritorna) la
-funzione \func{ClientEcho}, riportata in \nfig, si preoccupa di gestire la
+funzione \code{ClientEcho}, riportata in \nfig, si preoccupa di gestire la
 comunicazione, leggendo una riga alla volta dallo \file{stdin}, scrivendola
 sul socket e ristampando su \file{stdout} quanto ricevuto in risposta dal
 server. 
@@ -240,9 +240,9 @@ void ClientEcho(FILE * filein, int socket)
 La funzione utilizza due buffer per gestire i dati inviati e letti sul socket
 (\texttt{\small 3}).  La comunicazione viene gestita all'interno di un ciclo
 (linee \texttt{\small 5--10}), i dati da inviare sulla connessione vengono
-presi dallo \texttt{stdin} usando la funzione \func{fgets} che legge una
+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
-\texttt{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione
+\macro{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}).
@@ -307,15 +307,15 @@ tcp        0      0 roke:echo               gont:32981              ESTABLISHED
 \end{verbatim}
 mentre per quanto riguarda l'esecuzione dei programmi avremo che:
 \begin{itemize}
-\item il client chiama la funzione \func{ClientEcho} che si blocca sulla
+\item il client chiama la funzione \code{ClientEcho} che si blocca sulla
   \func{fgets} dato che non si è ancora scritto nulla sul terminale.
 \item il server eseguirà una \func{fork} facendo chiamare al processo figlio
-  la funzione \func{ServEcho}, quest'ultima si bloccherà sulla \func{read}
+  la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
   dal socket sul quale ancora non sono presenti dati.
 \item il processo padre del server chiamerà di nuovo \func{accept}
   bloccandosi fino all'arrivo di un'altra connessione.
 \end{itemize}
-e se usiamo il comando \ps{ps} per esaminare lo stato dei processi otterremo
+e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
 un risultato del tipo:
 \begin{verbatim}
 [piccardi@roke piccardi]$ ps ax
@@ -357,7 +357,7 @@ punto avremo:
 tcp        0      0 *:echo                  *:*                     LISTEN
 tcp        0      0 localhost:33032         localhost:echo          TIME_WAIT
 \end{verbatim} %$
-con il client che entra in \macro{TIME\_WAIT}.
+con il client che entra in \texttt{TIME\_WAIT}.
 
 Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
 terminazione normale della connessione, che ci servirà poi da riferimento nei
@@ -366,24 +366,24 @@ casi seguenti:
 \begin{enumerate}
 \item inviando un carattere di EOF da terminale la \func{fgets} ritorna
   restituendo un puntatore nullo che causa l'uscita dal ciclo di
-  while, così la \func{ClientEcho} ritorna.
-\item al ritorno di \func{ClientEcho} ritorna anche la funzione \func{main}, e
+  while, così la \code{ClientEcho} ritorna.
+\item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
   come parte del processo terminazione tutti i file descriptor vengono chiusi
   (si ricordi quanto detto in \secref{sec:proc_term_conclusion}); questo causa
   la chiusura del socket di comunicazione; il client allora invierà un FIN al
   server a cui questo risponderà con un ACK.  A questo punto il client verrà a
-  trovarsi nello stato \macro{FIN\_WAIT\_2} ed il server nello stato
-  \macro{CLOSE\_WAIT} (si riveda quanto spiegato in
+  trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
+  \texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
   \secref{sec:TCPel_conn_term}).
 \item quando il server riceve il FIN la \func{read} del processo figlio che
   gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
-  ciclo di while e il ritorno di \func{ServEcho}, a questo punto il processo
+  ciclo di while e il ritorno di \code{ServEcho}, a questo punto il processo
   figlio termina chiamando \func{exit}.
 \item all'uscita del figlio tutti i file descriptor vengono chiusi, la
   chiusura del socket connesso fa sì che venga effettuata la sequenza finale
   di chiusura della connessione, viene emesso un FIN dal server che riceverà
   un ACK dal client, a questo punto la connessione è conclusa e il client
-  resta nello stato \func{TIME\_WAIT}.
+  resta nello stato \texttt{TIME\_WAIT}.
 \item 
 \end{enumerate}
 
@@ -411,3 +411,8 @@ 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}).
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: