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: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[])
{
\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
+\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 \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
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;
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}
+ \label{fig:TCPsimpl_server_elem_sub}
\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}
+\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
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
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.
\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;
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
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
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}
+\item il server eseguirà una \texttt{fork} facendo chiamare al processo figlio
+ 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_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 \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}
+
+
+\subsection{La gestione dei processi figli}
+\label{sec:TCPsimpl_child_hand}
+
+Tutto questo riguarda la connessione, c'è però un'altro effetto del
+procedimento di chiusura del processo figlio nel server, e cioè l'invio del
+segnale \texttt{SIGCHILD} al padre. Dato che non si è installato un
+manipolatore (vedi \secref{cha:signals} per le problematiche relative) e che
+l'azione di default per questo segnale è quella di essere ignorato quello che
+avremo è che il processo figlio entrerà nello stato di zombie, come risulta
+una volta che ripetiamo il comando \texttt{ps}:
+\begin{verbatim}
+ 2356 pts/0 S 0:00 ./echod
+ 2359 pts/0 Z 0:00 [echod <defunct>]
+\end{verbatim}
+Poiché non è possibile lasciare processi zombie (che pur inattivi occupano
+spazio nella tabella dei processi e a lungo andare saturerebbero le risorse
+del kernel occorrerà gestire il segnale, per questo installeremo un
+manipolatore usando la funzione \texttt{Signal} (trattata in dettaglio in
+\secref{sec:sig_signal}).
projects / gapil.git / blobdiff