From 6e3e4f4d9d97e5643f85a13904412f4f4e46631f Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Wed, 20 Jun 2001 22:03:37 +0000 Subject: [PATCH] Sistemati gli esempi e riarrangiate le pagine --- fileintro.tex | 5 +- network.tex | 4 +- simpltcp.tex | 163 +++++++++++++++++++++++++++--------- sources/ElemEchoTCPClient.c | 6 +- sources/ElemEchoTCPServer.c | 6 +- 5 files changed, 133 insertions(+), 51 deletions(-) diff --git a/fileintro.tex b/fileintro.tex index a2735a7..fde0747 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -220,7 +220,7 @@ torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}. Come detto in precedenza esistono vari tipi di oggetti implementati del VFS per i quali è disponibile l'interfaccia astratta da esso provveduta. Un elenco -dei vari tipi di file è il seguente: +dei vari tipi di file definiti nel VFS è il seguente: \begin{table}[htb] \begin{center} @@ -266,7 +266,8 @@ Una seconda differenza codificata in maniera diversa da Windows o MacIntosh, in particolare il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|) del mac e del \texttt{CR LF} di Windows. Questo può causare alcuni -problemi qualora si facciano assunzioni sul terminatore della riga. +problemi qualora nei programmi si facciano assunzioni sul terminatore della +riga. \section{Una panoramica sull'uso dei file} diff --git a/network.tex b/network.tex index fc5113d..a37ca6d 100644 --- a/network.tex +++ b/network.tex @@ -121,7 +121,7 @@ int main(int argc, char *argv[]) \label{fig:net_cli_code} \end{figure} -Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che +Il sorgente completo del programma (\texttt{ElemDaytimeTCPClient.c}, che comprende il trattamento delle opzioni e una funzione per stampare un messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e può essere compilato su una qualunque macchina Linux. @@ -186,7 +186,7 @@ necessario deve provvedere il programma stesso. Dopo aver illustrato il client daremo anche un esempio di un server elementare, in grado di rispondere al precedente client. Il listato è nuovamente mostrato in \nfig, il sorgente completo -(\texttt{SimpleDaytimeTCPServer.c}) è allegato insieme agli altri file nella +(\texttt{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella directory \texttt{sources}. \begin{figure}[!htbp] diff --git a/simpltcp.tex b/simpltcp.tex index 4b2efec..6101387 100644 --- a/simpltcp.tex +++ b/simpltcp.tex @@ -35,20 +35,26 @@ risponde alle richieste di un client; tutto quello che cambia nel caso si una applicazione più complessa è la elaborazione dell'input del client da parte del server nel fornire le risposte in uscita. +Partiremo da una implementazione elementare che dovrà essere rimaneggiata di +volta in volta per poter tenere conto di tutte le evenienze che si possono +manifestare nella vita reale di una applicazione di rete, fino ad arrivare ad +una implementazione completa. + \subsection{La struttura del server} \label{sec:TCPsimp_server_main} -Il server si compone di un corpo principale, costituito dalla funzione -\texttt{main} che 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, è sostanzialmente -identica a quella vista nell'esempio in \secref{sec:TCPelem_serv_code}. +La prima versione del server, \texttt{ElemEchoTCPServer.c}, si compone di un +corpo principale, costituito dalla funzione \texttt{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 +esaminato in \secref{sec:TCPelem_serv_code}. \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} /* Subroutines declaration */ -void SockEcho(int sockfd); +void ServEcho(int sockfd); /* Program beginning */ int main(int argc, char *argv[]) { @@ -105,16 +111,17 @@ int main(int argc, char *argv[]) \label{fig:TCPsimpl_serv_code} \end{figure} -La struttura di questa prima versione del server è sostanzialmente a quella -dell'esempio precedente, ed ad esso si applicano le considerazioni fatte in +La struttura di questa prima versione del server è sostanzialmente identica a +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:TCPelem_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 \texttt{SockEcho}. Per ogni connessione viene creato un -processo figlio, il quale si incarica di lanciare la funzione -\texttt{SockEcho}. +delegata alla funzione \texttt{ServEcho}. +% Per ogni connessione viene creato un +% processo figlio, il quale si incarica di lanciare la funzione +% \texttt{SockEcho}. -Il codice della funzione \texttt{SockEcho} è invece mostrata in \nfig, la +Il codice della funzione \texttt{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 @@ -123,16 +130,11 @@ 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 \texttt{write}. -Quando il client chiude la connessione il ricevimento del FIN fa ritornare la -\texttt{read} con un numero di byte letti pari a zero, il che causa l'uscita -dal ciclo e il ritorno della funzione, che a sua volta causa la terminazione -del processo figlio. - \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} -void SockEcho(int sockfd) { +void ServEcho(int sockfd) { char buffer[MAXLINE]; int nread, nwrite; @@ -143,11 +145,16 @@ void SockEcho(int sockfd) { return; } \end{lstlisting} - \caption{Codice della prima versione della funzione \texttt{SockEcho} per la + \caption{Codice della prima versione della funzione \texttt{ServEcho} per la gestione del servizio \texttt{echo}.} \label{fig:TCPsimpl_sockecho_code} \end{figure} +Quando il client chiude la connessione il ricevimento del FIN fa ritornare la +\texttt{read} con un numero di byte letti pari a zero, il che causa l'uscita +dal ciclo e il ritorno della funzione, che a sua volta causa la terminazione +del processo figlio. + \subsection{Il client} \label{sec:TCPsimp_server_main} @@ -188,7 +195,7 @@ int main(int argc, char *argv[]) return -1; } /* read daytime from server */ - EchoClient(stdin, sock_fd); + ClientEcho(stdin, sock_fd); /* normal exit */ return 0; } @@ -203,8 +210,8 @@ 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 \texttt{connect} ritorna) La -funzione \texttt{EchoClient}, riportata in \nfig, si preoccupa di gestire la +Completata la connessione (quando la funzione \texttt{connect} ritorna) la +funzione \texttt{ClientEcho}, riportata in \nfig, si preoccupa di gestire la comunicazione, leggendo una riga alla volta dallo \texttt{stdin}, scrivendola sul socket e ristampando su \texttt{stdout} quanto ricevuto in risposta dal server. @@ -212,7 +219,7 @@ server. \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} -void EchoClient(FILE * filein, int socket) +void ClientEcho(FILE * filein, int socket) { char sendbuff[MAXLINE], recvbuff[MAXLINE]; int nread; @@ -225,7 +232,7 @@ void EchoClient(FILE * filein, int socket) return; } \end{lstlisting} - \caption{Codice della prima versione della funzione \texttt{EchoClient} per + \caption{Codice della prima versione della funzione \texttt{ClientEcho} per la gestione del servizio \texttt{echo}.} \label{fig:TCPsimpl_sockecho_code} \end{figure} @@ -237,7 +244,7 @@ presi dallo \texttt{stdin} usando la funzione \texttt{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 \texttt{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo -l'invio multiplo, qualora una singola \texttt{write} non basta, come spiegato +l'invio multiplo qualora una singola \texttt{write} non basti, come spiegato in \secref{sec:sock_io_behav}). I dati che vengono riletti indietro con una \texttt{SockRead} sul buffer di @@ -271,45 +278,119 @@ porta 7 che la sequenza delle chiamate a \texttt{socket}, \texttt{bind}, \texttt{listen} e poi si bloccherà nella \texttt{accept}. A questo punto si potrà controllarne lo stato con \texttt{netstat}: - \begin{verbatim} -[piccardi@roke piccardi]$ netstat -ant +[piccardi@roke piccardi]$ netstat -at Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 *:echo *:* LISTEN ... \end{verbatim} %$ - -che ci mostra come il socket sia in ascolto sulla porta richiesta, accendo +che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando connessioni da qualunque indirizzo e da qualunque porta e su qualunque interfaccia locale. A questo punto si può lanciare il client, esso chiamerà \texttt{socket} e -\texttt{connect}, una volta completato il three way handshake la funzione -\texttt{connect} ritornerà nel client e la \texttt{accept} nel server e la -connessione è stabilita, usando di nuovo \texttt{netstat} otterremmo: +\texttt{connect}, una volta completato il three way handshake la connessione è +stabilita; la \texttt{connect} ritornerà nel client\footnote{si noti che è + sempre la \texttt{connect} del client a ritornare per prima, in quanto + questo avviene alla ricezione del secondo segmento (l'ACK del server) del + three way handshake, la \texttt{accept} del server ritorna solo dopo + un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene + ricevuto.} e la \texttt{accept} nel server, ed usando di nuovo +\texttt{netstat} otterremmo che: \begin{verbatim} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:echo *:* LISTEN tcp 0 0 roke:echo gont:32981 ESTABLISHED \end{verbatim} - -A questo punto lo stato è il seguente: - - +mentre per quanto riguarda l'esecuzione dei programmi avremo che: \begin{itemize} -\item il client chiama la funzione \texttt{EchoClient} che si blocca sulla +\item il client chiama la funzione \texttt{ClientEcho} che si blocca sulla \texttt{fgets} dato che non si è ancora scritto nulla sul terminale. \item il server eseguirà una \texttt{fork} facendo chiamare al processo figlo - la funzione \texttt{SockEcho}, quest'ultima si bloccherà sulla \texttt{read} + la funzione \texttt{ServEcho}, quest'ultima si bloccherà sulla \texttt{read} dal socket sul quale ancora non sono presenti dati. -\item il +\item il processo padre del server chiamerà di nuovo \texttt{accept} + bloccandosi fino all'arrivo di un'altra connessione. \end{itemize} -il server eseguira una \texttt{fork} facendo chiamare al -processo figlo la funzione \texttt{SockEcho}, la quale eseguirà una read s +e se usiamo il comando \texttt{ps} per esaminare lo stato dei processi +otterremo un risultato del tipo: +\begin{verbatim} +[piccardi@roke piccardi]$ ps ax + PID TTY STAT TIME COMMAND + ... ... ... ... ... + 2356 pts/0 S 0:00 ./echod + 2358 pts/1 S 0:00 ./echo 127.0.0.1 + 2359 pts/0 S 0:00 ./echod +\end{verbatim} %$ +(dove si sono cancellate le righe inutili) da cui si evidenzia la presenza di +tre processi, tutti in stato di \textit{sleep} (S). +Se a questo punto si inizia a scrivere qualcosa sul client niente sarà +trasmesso fin tanto che non si prema il ritorno carrello, allora la +\texttt{fgets} ritornerà e a questo punto il client scriverà quanto immesso +sul socket, poi rileggerà quanto gli viene inviato all'indietro dal server, e +questo sarà inviato sullo standard output, che nel caso ne provoca +l'immediatamente stampa a video. +\subsection{La conclusione normale} +\label{sec:TCPsimpl_startup} +Tutto quello che scriveremo sul client sarà rimandato indietro dal server e +ristampato a video fintanto che non concluderemo l'immissione dei dati; una +sessione tipica sarà allora del tipo: +\begin{verbatim} +[piccardi@roke sources]$ ./echo 127.0.0.1 +Questa e` una prova +Questa e` una prova +Ho finito +Ho finito +\end{verbatim} %$ +che termineremo inviando un EOF dal terminale (usando la combinazione di tasti +ctrl-D, che non compare a schermo); se eseguiamo un \texttt{netstat} a questo +punto avremo: +\begin{verbatim} +[piccardi@roke piccardi]$ netstat -at +tcp 0 0 *:echo *:* LISTEN +tcp 0 0 localhost:33032 localhost:echo TIME_WAIT +\end{verbatim} %$ +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 +casi seguenti: + +\begin{enumerate} +\item Inviando un carattere di EOF da terminale la \texttt{fgets} ritorna + restituendo un puntatore nullo che causa l'uscita dal ciclo di + \texttt{while}, così la \texttt{ClientEcho} ritorna. +\item Al ritorno di \texttt{ClientEcho} ritorna anche la funzione + \texttt{main}, e come parte del processo terminazione tutti i file + descriptor vengono chiusi (si ricordi quanto visto in + \secref{sec:proc_term_conclusion}), il che 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 \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 la \texttt{read} del processo figlio + che gestisce la connessione ritorna restituendo 0 causando così l'uscita dal + ciclo di \texttt{while} e il ritorno di \texttt{ServEcho}, a questo punto il + processo figlio termina chiamando \texttt{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 \texttt{TIME\_WAIT}. +\item +\end{enumerate} + + + + +\begin{verbatim} + 2356 pts/0 S 0:00 ./echod + 2359 pts/0 Z 0:00 [echod ] +\end{verbatim} diff --git a/sources/ElemEchoTCPClient.c b/sources/ElemEchoTCPClient.c index 97eba19..eafdc81 100644 --- a/sources/ElemEchoTCPClient.c +++ b/sources/ElemEchoTCPClient.c @@ -8,7 +8,7 @@ * * Usage: echo -h give all info's * - * $Id: ElemEchoTCPClient.c,v 1.1 2001/06/18 21:46:14 piccardi Exp $ + * $Id: ElemEchoTCPClient.c,v 1.2 2001/06/20 22:03:37 piccardi Exp $ * ****************************************************************/ /* @@ -24,7 +24,7 @@ #define MAXLINE 256 void usage(void); -void EchoClient(FILE * filein, int socket); +void ClientEcho(FILE * filein, int socket); /* Program begin */ int main(int argc, char *argv[]) @@ -99,7 +99,7 @@ void usage(void) { exit(1); } -void EchoClient(FILE * filein, int socket) +void ClientEcho(FILE * filein, int socket) { char sendbuff[MAXLINE], recvbuff[MAXLINE]; int nread; diff --git a/sources/ElemEchoTCPServer.c b/sources/ElemEchoTCPServer.c index f7a1a41..7df6fed 100644 --- a/sources/ElemEchoTCPServer.c +++ b/sources/ElemEchoTCPServer.c @@ -8,7 +8,7 @@ * * Usage: echod * - * $Id: ElemEchoTCPServer.c,v 1.1 2001/06/18 21:46:14 piccardi Exp $ + * $Id: ElemEchoTCPServer.c,v 1.2 2001/06/20 22:03:37 piccardi Exp $ * ****************************************************************/ /* @@ -28,7 +28,7 @@ /* Subroutines declaration */ void usage(void); -void SockEcho(int sockfd); +void ServEcho(int sockfd); /* Program beginning */ int main(int argc, char *argv[]) { @@ -124,7 +124,7 @@ void usage(void) { /* * routine to handle echo for connection */ -void SockEcho(int sockfd) { +void ServEcho(int sockfd) { char buffer[MAXLINE]; int nread, nwrite; -- 2.30.2