X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=simpltcp.tex;h=4d46b1a2deecb3eea0b9d6cae8566d270ed7cd2f;hp=4b2efecbfd09d47887d2f1a33cc069da0ffc7de8;hb=86e903a44e57cf2d3fe122693fae4319fc8ba89e;hpb=4ff5f41266fec476e9a8d2d2d2cf4c58f8bb5590 diff --git a/simpltcp.tex b/simpltcp.tex index 4b2efec..4d46b1a 100644 --- a/simpltcp.tex +++ b/simpltcp.tex @@ -1,3 +1,13 @@ +%% simpltcp.tex +%% +%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to +%% copy, distribute and/or modify this document under the terms of the GNU Free +%% Documentation License, Version 1.1 or any later version published by the +%% Free Software Foundation; with the Invariant Sections being "Prefazione", +%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the +%% license is included in the section entitled "GNU Free Documentation +%% License". +%% \chapter{Un esempio completo di client/server TCP} \label{cha:simple_TCP_sock} @@ -8,16 +18,16 @@ comunicazione in entrambe le direzioni. 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. +durante l'impiego di un'applicazione di rete. \section{Il servizio \texttt{echo}} \label{sec:TCPsimp_echo} -L'applicazione scelta come esempio sarà una implementazione elementare, ma +L'applicazione scelta come esempio sarà un'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 @@ -29,33 +39,39 @@ caratteri dallo standard input e la scrive sul server, il server legger linea dalla connessione e la riscriverà all'indietro; sarà compito del client leggere la risposta del server e stamparla sullo standard output. -Si è scelto di usare questo servizio, seguendo lo Stevens, perché costituisce -il prototipo ideale di una generica applicazione di rete in cui un server -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. +Si è scelto di usare questo servizio, seguendo l'esempio di \cite{UNP1}, +perché costituisce il prototipo ideale di una generica applicazione di rete in +cui un server 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 un'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 un'applicazione di rete, fino ad arrivare ad +un'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, \file{ElemEchoTCPServer.c}, si compone di un +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 \figref{fig:TCPsimpl_serv_code}, è analoga a quella vista +nel precedente esempio esaminato in \secref{sec:TCPel_cunc_serv}. \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} /* Subroutines declaration */ -void SockEcho(int sockfd); +void ServEcho(int sockfd); /* Program beginning */ int main(int argc, char *argv[]) { int list_fd, conn_fd; pid_t pid; struct sockaddr_in serv_add; - .... + ... /* create socket */ if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("Socket creation error"); @@ -100,39 +116,35 @@ 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} -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}. - -Il codice della funzione \texttt{SockEcho} è 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 -viene invece gestita dalla funzione \texttt{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 -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. - +\figref{fig:TCPel_serv_code} sono che in questo caso per il socket in ascolto +viene usata la porta 7 e che tutta la gestione della comunicazione è 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 \code{ServEcho} è invece mostrata in +\figref{fig:TCPsimpl_server_elem_sub}, 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 \func{read} (che ritorna solo in +presenza di dati in arrivo), la riscrittura viene invece gestita dalla +funzione \func{SockWrite} (descritta 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 +\func{write}. \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} -void SockEcho(int sockfd) { +void ServEcho(int sockfd) { char buffer[MAXLINE]; int nread, nwrite; @@ -143,20 +155,25 @@ 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 \code{ServEcho} per la gestione del servizio \texttt{echo}.} - \label{fig:TCPsimpl_sockecho_code} + \label{fig:TCPsimpl_server_elem_sub} \end{figure} +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 della funzione, che a sua volta causa la terminazione +del processo figlio. + \subsection{Il client} -\label{sec:TCPsimp_server_main} +\label{sec:TCPsimp_client_main} -Il codice del client è riportato in \nfig, anche esso ricalca la struttura del -precedente client per il servizio \texttt{daytime} (vedi -\secref{sec:net_cli_sample}) ma, come per il server, lo si è diviso in due -parti, inserendo la parte relativa alle operazioni specifiche previste per il -protocollo \texttt{echo} in una funzione a parte. +Il codice del client è riportato in \figref{fig:TCPsimpl_client_elem}, anche +esso ricalca la struttura del precedente client per il servizio +\texttt{daytime} (vedi \secref{sec:net_cli_sample}) ma, come per il server, lo +si è diviso in due parti, inserendo la parte relativa alle operazioni +specifiche previste per il protocollo \texttt{echo} in una funzione a parte. \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} @@ -188,31 +205,31 @@ int main(int argc, char *argv[]) return -1; } /* read daytime from server */ - EchoClient(stdin, sock_fd); + ClientEcho(stdin, sock_fd); /* normal exit */ return 0; } \end{lstlisting} \caption{Codice della prima versione del client \texttt{echo}.} - \label{fig:TCPsimpl_sockecho_code} + \label{fig:TCPsimpl_client_elem} \end{figure} -La funzione \texttt{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 \texttt{connect} ritorna) La -funzione \texttt{EchoClient}, 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. +Completata la connessione, al ritorno di \func{connect}, la funzione +\code{ClientEcho}, riportata in \figref{fig:TCPsimpl_client_echo_sub}, 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. \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,27 +242,27 @@ 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} + \label{fig:TCPsimpl_client_echo_sub} \end{figure} 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 \texttt{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 -\texttt{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo -l'invio multiplo, qualora una singola \texttt{write} non basta, come spiegato +\const{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}). -I dati che vengono riletti indietro con una \texttt{SockRead} sul buffer di +I dati che vengono riletti indietro con una \func{SockRead} sul buffer di ricezione e viene inserita la terminazione della stringa (\texttt{\small - 7--8}) e per poter usare la funzione \texttt{fputs} per scriverli su -\texttt{stdout}. + 7--8}) e per poter usare la funzione \func{fputs} per scriverli su +\file{stdout}. -Un end of file inviato su \texttt{stdin} causa il ritorno di \texttt{fgets} +Un end of file inviato su \file{stdin} causa il ritorno di \func{fgets} con un puntatore nullo e l'uscita dal ciclo, al che la subroutine ritorna ed il client esce. @@ -255,11 +272,11 @@ il client esce. Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà di considerare in dettaglio tutte le problematiche che si possono incontrare -nello scrivere una applicazione di rete; infatti attraverso l'esame delle sue +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 gradi di scrivere applicazioni robuste, in grado di +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. @@ -268,48 +285,166 @@ 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 \texttt{socket}, \texttt{bind}, \texttt{listen} e -poi si bloccherà nella \texttt{accept}. A questo punto si potrà controllarne -lo stato con \texttt{netstat}: - +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{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: +A questo punto si può lanciare il client, esso chiamerà \func{socket} e +\func{connect}; una volta completato il three way handshake la connessione è +stabilita; la \func{connect} ritornerà nel client\footnote{si noti che è + sempre la \func{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 \func{accept} del server ritorna solo dopo + un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene + ricevuto.} e la \func{accept} nel server, ed usando di nuovo +\cmd{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 - \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} +\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 \code{ServEcho}, quest'ultima si bloccherà sulla \func{read} dal socket sul quale ancora non sono presenti dati. -\item il +\item il processo padre del server chiamerà di nuovo \func{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 \cmd{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} (vedi +\tabref{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 \secref{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'immediatamente stampa a video. + + +\subsection{La conclusione normale} +\label{sec:TCPsimpl_conclusion} + +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 \cmd{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 +quando affronteremo il comportamento in caso di conclusioni anomale: + +\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 + \code{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 \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 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 \texttt{TIME\_WAIT}. + +\end{enumerate} + + +\subsection{La gestione dei processi figli} +\label{sec:TCPsimpl_child_hand} + +Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto +del procedimento di chiusura del processo figlio nel server (si veda quanto +esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del +segnale \const{SIGCHLD} al padre, ma dato che non si è installato un +gestore e che l'azione predefinita per questo segnale è quella di essere +ignorato, non avendo predisposto la ricezione dello stato di terminazione, +otterremo che il processo figlio entrerà nello stato di zombie\index{zombie} +(si riveda quanto illustrato in \secref{sec:sig_sigchld}), come risulterà +ripetendo il comando \cmd{ps}: +\begin{verbatim} + 2356 pts/0 S 0:00 ./echod + 2359 pts/0 Z 0:00 [echod ] +\end{verbatim} + +Poiché non è possibile lasciare processi zombie\index{zombie} che pur inattivi +occupano spazio nella tabella dei processi e a lungo andare saturerebbero le +risorse del kernel, occorrerà ricevere opportunamente lo stato di terminazione +del processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando +\const{SIGCHLD} secondo quanto illustrato in \secref{sec:sig_sigchld}. + +La prima modifica al nostro server è pertanto quella di inserire la gestione +della terminazione dei processi figli attraverso l'uso di un gestore. +Per questo useremo la funzione \code{Signal}, illustrata in +\figref{fig:sig_Signal_code}, per installare il semplice gestore che +riceve i segnali dei processi figli terminati già visto in +\figref{fig:sig_sigchld_handl}; aggiungendo il seguente codice: +\begin{lstlisting}{} + ... + /* install SIGCHLD handler */ + Signal(SIGCHLD, sigchld_hand); /* establish handler */ + /* create socket */ + ... +\end{lstlisting} +\noindent +all'esempio illustrato in \figref{fig:TCPsimpl_serv_code}, e linkando il tutto +alla funzione \code{sigchld\_hand}, si risolverà completamente il problema +degli zombie\index{zombie}. +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: