X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=elemtcp.tex;h=534dd398f18819943c1811ed5bbb63fcf5d556ab;hp=b021a78ce2f930973fb330c63c66ca67b4761746;hb=5e54ad63881cd5bd7c71395d073127e41f1b68d6;hpb=e3e15ed6d698e5cc35f3b7f4c5db96adc38255c3 diff --git a/elemtcp.tex b/elemtcp.tex index b021a78..534dd39 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -233,9 +233,9 @@ comporta ad esempio che se un processo viene terminato da un segnale tutte le connessioni aperte verranno chiuse. Infine occorre sottolineare che, benché nella figura (e nell'esempio che -vedremo più avanti in \secref{sec:TCPsimp_echo}) sia stato il client ad -eseguire la chiusura attiva, nella realtà questa può essere eseguita da uno -qualunque dei due capi della comunicazione (come nell'esempio di +vedremo più avanti in \secref{sec:TCP_echo}) sia stato il client ad eseguire +la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque +dei due capi della comunicazione (come nell'esempio di \figref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune resta quello del client, ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali è il server ad effettuare la chiusura attiva. @@ -445,7 +445,7 @@ Quando un client contatta un server deve poter identificare con quale dei vari possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che identificano una serie di servizi noti (ad esempio la porta 22 identifica il -servizio \texttt{ssh}) effettuati da appositi server che rispondono alle +servizio \textit{ssh}) effettuati da appositi server che rispondono alle connessioni verso tali porte. D'altra parte un client non ha necessità di usare un numero di porta @@ -503,7 +503,7 @@ tabelle. I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che corrispondono alle porte con numero minore di 1024 e coincidono quindi con le porte conosciute). La loro caratteristica è che possono essere assegnate a un -socket solo da un processo con i privilegi di root, per far si che solo +socket solo da un processo con i privilegi di amministratore, per far si che solo l'amministratore possa allocare queste porte per far partire i relativi servizi. @@ -1591,7 +1591,7 @@ un po' pi le direzioni. Ci limiteremo a fornire una implementazione elementare, che usi solo le -funzioni di base viste finore, ma prenderemo in esame, oltre al comportamento +funzioni di base viste finora, ma 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 un'applicazione di rete, partendo @@ -1618,11 +1618,11 @@ da parte di un server che risponde fornendo altri dati in uscita. Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti direttamente dal superserver \cmd{inetd}, ed è definito dall'\href{http://www.ietf.org/rfc/rfc0862.txt}{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 uscita, fintanto che il chiamante non ha chiude la -connessione; il servizio opera sulla porta 7. +servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in +ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per +il primo stabilisce che una volta stabilita la connessione ogni dato in +ingresso deve essere rimandato in uscita fintanto che il chiamante non ha +chiude la connessione. Al servizio è assegnata la porta riservata 7. Nel nostro caso l'esempio sarà costituito da un client che legge una linea di caratteri dallo standard input e la scrive sul server. A sua volta il server @@ -1634,8 +1634,8 @@ output. \subsection{Il client: prima versione} \label{sec:TCP_echo_client} -Il codice della prima versione client per il servizio \textit{echo}, -diponibile nel file \file{TCP_echo1.c}, è riportato in +Il codice della prima versione del client per il servizio \textit{echo}, +disponibile nel file \file{TCP\_echo1.c}, è riportato in \figref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente client per il servizio \textit{daytime} (vedi \secref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) è @@ -1644,7 +1644,7 @@ sostanzialmente identica, a parte l'uso di una porta diversa. \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15.6 cm} - \includecodesample{listati/TCP_echo_client.c} + \includecodesample{listati/TCP_echo1.c} \end{minipage} \normalsize \caption{Codice della prima versione del client \textit{echo}.} @@ -1652,22 +1652,22 @@ sostanzialmente identica, a parte l'uso di una porta diversa. \end{figure} Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a -riga di comando; una volta dichiarate le variabili, si prosegue -(\texttt{\small 10--13}) con della creazione del socket, con l'usuale -controllo degli errori, la preparazione (\texttt{\small 14--17}) della -struttura dell'indirizzo, che usa la porta 7 riservata al servizio -\textit{echo}, l'indirizzo specificato a riga di comando appositamente -convertito (\texttt{\small 18--22}). Una volta inizializzato l'indirizzo si si -può eseguire (\texttt{\small 23--27}) la connessione al server secondo la -stessa modalità usata in \secref{sec:TCP_daytime_client}. - -Completata la connessione, al ritorno di \func{connect}, per gestire il -funzionamento del protocollo si usa la funzione \code{ClientEcho}, il cui -codice si è riportato a parte in \figref{fig:TCPsimpl_client_echo_sub}. Questa -si preoccupa di gestire tutta la comunicazione, leggendo una riga alla volta -dallo standard input \file{stdin}, scrivendola sul socket e ristampando su -\file{stdout} quanto ricevuto in risposta dal server. Al ritorno dalla -funzione (\texttt{\small 30--31}) anche il programma termina. +riga di comando. Una volta dichiarate le variabili, si prosegue +(\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo +degli errori, alla preparazione (\texttt{\small 14--17}) della struttura +dell'indirizzo, che stavolta usa la porta 7 riservata al servizio +\textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo +specificato a riga di comando. A questo punto (\texttt{\small 23--27}) si può +eseguire la connessione al server secondo la stessa modalità usata in +\secref{sec:TCP_daytime_client}. + +Completata la connessione, per gestire il funzionamento del protocollo si usa +la funzione \code{ClientEcho}, il cui codice si è riportato a parte in +\figref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la +comunicazione, leggendo una riga alla volta dallo standard input \file{stdin}, +scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in +risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche +il programma termina. La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per gestire i dati inviati e letti sul socket. La comunicazione viene gestita @@ -1692,58 +1692,138 @@ funzione \func{fputs} per scriverli su \file{stdout}. \normalsize \caption{Codice della prima versione della funzione \texttt{ClientEcho} per la gestione del servizio \textit{echo}.} - \label{fig:TCPsimpl_client_echo_sub} + \label{fig:TCP_client_echo_sub} \end{figure} -Quando si conluderà l'invio di dati mandando un end-of-file sullo standard -inputo (ad esempio con la pressione di \texttt{C-d}) si avrà il ritorno di -\func{fgets} con un puntatore nullo (si riveda quanto spiegato in -\secref{sec:file_line_io}) e la conseguente uscita dal ciclo; al che la -subroutine ritorna ed il nostro programma client termina. +Quando si concluderà l'invio di dati mandando un end-of-file sullo standard +input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda +quanto spiegato in \secref{sec:file_line_io}) e la conseguente uscita dal +ciclo; al che la subroutine ritorna ed il nostro programma client termina. + +Si può effettuare una verifica del funzionamento del client abilitando il +servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria +macchina ed usandolo direttamente verso di esso in locale, vedremo in +dettaglio più avanti (in \secref{sec:TCP_echo_startup}) il funzionamento del +programma, usato però con la nostra versione del server \textit{echo}, che +illustriamo immediatamente. \subsection{Il server: prima versione} \label{sec:TCPsimp_server_main} -La prima versione del server, \file{TCP_echod.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:TCP_daytime_cunc_server}. +La prima versione del server, contenuta nel file \file{TCP\_echod.c}, è +riportata in \figref{fig:TCP_echo_server_code}. Come abbiamo fatto per il +client anche il server è stato diviso in un corpo principale, costituito dalla +funzione \code{main}, che è molto simile a quello visto nel precedente esempio +per il server del servizio \textit{daytime} di +\secref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria +\code{ServEcho} che si cura della gestione del servizio. -\begin{figure}[!htb] +\begin{figure}[!htbp] \footnotesize \centering \begin{minipage}[c]{15.6cm} - \includecodesample{listati/ElemEchoTCPServer.c} + \includecodesample{listati/TCP_echod.c} \end{minipage} \normalsize - \caption{Codice della funzione \code{main} della prima versione del server + \caption{Codice del corpo principale della prima versione del server per il servizio \textit{echo}.} - \label{fig:TCPsimpl_serv_code} + \label{fig:TCP_echo_server_code} \end{figure} -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:TCP_daytime_cunc_server}. Le uniche differenze rispetto -all'esempio in \figref{fig:TCP_daytime_cunc_server_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{FullWrite} (descritta in \figref{fig:sock_FullWrite_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}. +In questo caso però, rispetto a quanto visto nell'esempio di +\figref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server +curando maggiormente alcuni dettagli, per tenere conto anche di alcune +esigenze generali (che non riguardano direttamente la rete), come la +possibilità di lanciare il server anche in modalità interattiva e la cessione +dei privilegi di amministratore non appena questi non sono più necessari. + +La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del +server di \secref{sec:TCP_daytime_cunc_server}, ed ivi descritta in dettaglio: +crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato che +quest'ultima funzione viene usata su una porta riservata, il server dovrà +essere eseguito da un processo con i privilegi di amministratore, pena il +fallimento della chiamata. + +Una volta eseguita la funzione \func{bind} però i privilegi di amministratore +non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da +evitare problemi in caso di eventuali vulnerabilità del server. Per questo +prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il +processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534, + ovvero -1 per il formato \ctyp{short}, che di norma in tutte le + distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e + l'utente \texttt{nobody}, usati appunto per eseguire programmi che non + richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small + 27--30}) l'operazione usando \func{setuid} per cambiare anche +l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste + due operazioni è importante, infatti solo avendo i privilegi di + amministratore si può cambiare il gruppo di un processo ad un'altro di cui + non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una + successiva chiamata a \func{setgid}. Inoltre si ricordi (si riveda quanto + esposto in \secref{sec:proc_perms}) che usando queste due funzioni il + rilascio dei privilegi è irreversibile.} Infine (\texttt{\small 30--36}), +qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31}) +si apre il sistema di logging per la stampa degli errori, e poi +(\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il +processo come demone. + +A questo punto il programma riprende di nuovo lo schema già visto usato dal +server per il servizio \textit{daytime}, con l'unica differenza della chiamata +alla funzione \code{PrintErr}, riportata in \figref{fig:TCP_PrintErr}, al +posto di \func{perror} per la stampa degli errori. + +Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si +esegue indefinitamente il ciclo principale (\texttt{\small 42--58}). +All'interno di questo si ricevono (\texttt{\small 43--46}) le connessioni, +creando (\texttt{\small 47--50}) un processo figlio per ciascuna di esse. +Quest'ultimo (\texttt{\small 51--55}), chiuso (\texttt{\small 52}) il +\textit{listening socket}, esegue (\texttt{\small 53}) la funzione di gestione +del servizio \code{ServEcho}, ed al ritorno di questa (\texttt{\small 54}) +esce. + +Il padre invece si limita (\texttt{\small 56}) a chiudere il \textit{connected + socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In +questo modo si ha un server concorrente. La terminazione del padre non è +gestita esplicitamente, e deve essere effettuata inviando un segnale al +processo. + +Avendo trattato direttamente la gestione del programma come demone, si è +dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di +errore attraverso il sistema del \textit{syslog} trattato in +\secref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando come +\textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato in +\figref{fig:TCP_PrintErr}. + +In essa ci si limita a controllare se è stato impostato (valore attivo per +default) l'uso come demone, nel qual caso (\texttt{\small 3}) si usa +\func{syslog} per stampare il messaggio di errore fornito come argomento sui +log di sistema. Se invece si è in modalità interattiva (attivabile con +l'opzione \texttt{-i}) si usa semplicemente la funzione \func{perror} per +stampare sullo standard error. + \begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15.6cm} + \includecodesample{listati/PrintErr.c} + \end{minipage} + \normalsize + \caption{Codice della funzione \code{PrintErr} per la + generalizzazione della stampa degli errori sullo standard input o + attraverso il \texttt{syslog}.} + \label{fig:TCP_PrintErr} +\end{figure} + +La gestione del servizio \textit{echo} viene effettuata interamente nella +funzione \code{ServEcho}, il cui codice è mostrato in +\figref{fig:TCP_ServEcho}, la comunicazione viene gestita all'interno del +ciclo (\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{FullWrite} +(descritta in \figref{fig:sock_FullWrite_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 \centering \begin{minipage}[c]{15.6cm} \includecodesample{listati/ServEcho.c} @@ -1751,19 +1831,23 @@ dati di cui \normalsize \caption{Codice della prima versione della funzione \code{ServEcho} per la gestione del servizio \textit{echo}.} - \label{fig:TCPsimpl_server_elem_sub} + \label{fig:TCP_ServEcho} \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. - +Nella funzione si è anche inserita la possibilità (\texttt{\small 7--14}) di +inviare dei messaggi di debug (abilitabile con l'uso dell'opzione \texttt{-d} +che imposta opportunamente \var{debugging}), gestendo entrambi i casi in cui +la stampa deve essere effettuata tramite \func{syslog} (\texttt{\small 11}) o +direttamente sullo standard output (\texttt{\small 13}). +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{L'avvio e il funzionamento normale} -\label{sec:TCPsimpl_startup} +\label{sec:TCP_echo_startup} Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà di considerare in dettaglio tutte le problematiche che si possono incontrare @@ -1840,7 +1924,7 @@ l'immediatamente stampa a video. \subsection{La conclusione normale} -\label{sec:TCPsimpl_conclusion} +\label{sec:TCP_echo_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 @@ -1887,12 +1971,11 @@ quando affronteremo il comportamento in caso di conclusioni anomale: 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} +\label{sec:TCP_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 @@ -1908,23 +1991,28 @@ ripetendo il comando \cmd{ps}: 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: +Dato che non è il caso di lasciare processi zombie\index{zombie}, 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}. Una 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} della nostra libreria personale, che abbiamo illustrato in +\figref{fig:sig_Signal_code}, per installare il gestore che riceve i segnali +dei processi figli terminati già visto in \figref{fig:sig_sigchld_handl}. +Basterà allora aggiungere il seguente codice: \includecodesnip{listati/sigchildhand.c} \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}. +all'esempio illustrato in \figref{fig:TCP_echo_server_code}. + +In questo modo però si introduce un altro problema, + + + +\subsection{I vari scenari critici} +\label{sec:TCP_echo_critical} + +