X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=elemtcp.tex;h=d3178839f56981b5b2cb2403be16ae75b37e9d97;hp=94612fa7759e2fd4415015a93c33a0dca7adfaf2;hb=4826742c87d76af810c8a30e5495135fb43b8091;hpb=caa4d2b308da07b9522599555d07db6f67351601 diff --git a/elemtcp.tex b/elemtcp.tex index 94612fa..d317883 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -3,9 +3,10 @@ In questo capitolo inizieremo ad approndire la conoscenza dei socket TCP, tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate -nei due esempi elementari forniti in precedenza (vedi \ref{sec:net_cli_sample} -e \ref{sec:net_serv_sample}), previa una descrizione delle principali -caratteristiche del funzionamento di una connessione TCP. +nei due esempi elementari forniti in precedenza (vedi +\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}), previa una +descrizione delle principali caratteristiche del funzionamento di una +connessione TCP. La seconda parte del capitolo sarà poi dedicata alla scrittura di una prima semplice applicazione client/server completa, che implementi il servizio @@ -31,8 +32,8 @@ l'uso del programma \texttt{netstat}. Il processo che porta a creare una connessione TCP è chiamato \textit{three way handushake}; la successione tipica degli eventi (la stessa che si verifica utilizzando il codice dei due precedenti esempi elementari -\ref{fig:net_cli_code} e \ref{fig:net_serv_code}) che porta alla creazione di -una connessione è la seguente: +\figref{fig:net_cli_code} e \figref{fig:net_serv_code}) che porta alla +creazione di una connessione è la seguente: \begin{itemize} \item Il server deve essere preparato per accettare le connessioni in arrivo; @@ -55,7 +56,7 @@ una connessione \texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi, come \texttt{SYN} (che sta per \textit{sincronize}) corrispondono a funzioni particolari del protocollo e danno il nome al segmento, (per - maggiori dettagli vedere \ref{cha:tcp_protocol})}, in sostanza viene + maggiori dettagli vedere \capref{cha:tcp_protocol})}, in sostanza viene inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con il numero di sequenza iniziale e il flag \texttt{SYN}) e le opzioni di TCP. @@ -126,7 +127,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: connesione corrente. È possibile leggere e scrivere questo valore attraverso l'opzione del socket \texttt{TCP\_MAXSEG}. -\item \textit{window scale option} come spiegato in \ref{cha:tcp_protocol} il +\item \textit{window scale option} come spiegato in \capref{cha:tcp_protocol} il protocollo TCP implementa il controllo di flusso attraverso una \textsl{finestra annunciata} (\textit{advertized window}) con la quale ciascun capo della comunicazione dichiara quanto spazio disponibile ha in @@ -164,8 +165,8 @@ elevati. In ogni caso linux supporta pienamente entrambe le opzioni. Mentre per creare una connessione occorre un interscambio di tre segmenti, la procedura di chiusura ne richede quattro; ancora una volta si può fare -riferimento al codice degli esempi \ref{fig:net_cli_code} e -\ref{fig:net_serv_code}, in questo caso la successione degli eventi è la +riferimento al codice degli esempi \figref{fig:net_cli_code} e +\figref{fig:net_serv_code}, in questo caso la successione degli eventi è la seguente: \begin{enumerate} @@ -218,17 +219,17 @@ pi La emissione del FIN avviene quando il socket viene chiuso, questo però non avviene solo per la chiamata della funzione \texttt{close} (come in -\ref{fig:net_serv_code}), ma anche alla terminazione di un processo (come in -\ref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo viene -terminato da un segnale tutte le connessioni aperte verranno chiuse. +\figref{fig:net_serv_code}), ma anche alla terminazione di un processo (come +in \figref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo +viene terminato da un segnale tutte le connessioni aperte verranno chiuse. Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo -in \ref{sec:TCPel_echo_example}) sia il client ad eseguire la chiusura attiva, -nella realtà questa può essere eseguita da uno qualunque dei due capi della -comunicazione (come in fatto in precedenza da \ref{fig:net_serv_code}), e -benché quello del client sia il caso più comune ci sono alcuni servizi, il -principale dei quali è l'HTTP, per i quali è il server ad effettuare la -chiusura attiva. +in \secref{sec:TCPel_echo_example}) sia il client ad eseguire la chiusura +attiva, nella realtà questa può essere eseguita da uno qualunque dei due capi +della comunicazione (come in fatto in precedenza da +\figref{fig:net_serv_code}), e benché quello del client sia il caso più comune +ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali è il +server ad effettuare la chiusura attiva. \subsection{Un esempio di connessione} \label{sec:TCPel_conn_dia} @@ -242,7 +243,7 @@ che vengono riportati del comando \texttt{netstat} nel campo \textit{State}. Una descrizione completa del funzionamento del protocollo va al di là degli obiettivi di questo libro; un approfondimento sugli aspetti principali si -trova in \ref{cha:tcp_protocol}, ma per una trattazione esauriente il miglior +trova in \capref{cha:tcp_protocol}, ma per una trattazione esauriente il miglior riferimento resta (FIXME citare lo Stevens); qui ci limiteremo a descrivere brevemente un semplice esempio di connessione e le transizioni che avvengono nei due casi appena citati (creazione e terminazione della connessione). @@ -289,7 +290,7 @@ caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della risposta. Infine si ha lo scambio dei quattro segmenti che terminano la connessione -secondo quanto visto in \ref{sec:TCPel_conn_term}; si noti che il capo della +secondo quanto visto in \secref{sec:TCPel_conn_term}; si noti che il capo della connessione che esegue la chiusura attiva entra nello stato \textsl{TIME\_WAIT} su cui torneremo fra poco. @@ -329,7 +330,7 @@ La MSL sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}). Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di -IP (per maggiori dettagli vedi \ref{sec:appA_xxx}), e viene decrementato ad +IP (per maggiori dettagli vedi \secref{sec:appA_xxx}), e viene decrementato ad ogni passaggio da un router; quando si annulla il pacchetto viene scartato. Siccome il numero è ad 8 bit il numero massimo di ``salti'' è di 255, pertanto anche se il TTL (da \textit{time to live}) non è propriamente un limite sul @@ -422,7 +423,7 @@ In un ambiente multitasking in un dato momento pi usare sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea. Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i \textsl{numeri di porta}, che fanno parte, come si può -vedere in \ref{sec:sock_sa_ipv4} e \ref{sec:sock_sa_ipv6} pure delle strutture +vedere in \secref{sec:sock_sa_ipv4} e \secref{sec:sock_sa_ipv6} pure delle strutture degli indirizzi del socket. Quando un client contatta un server deve poter identificare con quale dei vari @@ -508,7 +509,7 @@ campi \textit{Local Address} e \textit{Foreing Address}. Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a che fare con un'applicazione client/server (come quella che scriveremo in -\ref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel +\secref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel caso di un server TCP che deve gestire connessioni multiple. Se esguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere @@ -600,14 +601,14 @@ alla porta 21101 al secondo. In questa sezione descriveremo in dettaglio le varie funzioni necessarie per l'uso dei socket TCP già citate in precedenza (e utilizzate nei due esempi -\ref{sec:net_cli_sample} e \ref{sec:net_serv_sample}) con l'eccezione della -funzione \texttt{socket} che è già stata esaminata in dettaglio in -\ref{sec:sock_socket}. +\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}) con l'eccezione +della funzione \texttt{socket} che è già stata esaminata in dettaglio in +\secref{sec:sock_socket}. In \nfig\ abbiamo un tipico schema di funzionamento di un'applicazione client-server che usa i socket TCP: prima il server viene avviato ed in seguito il client si connette, in questo caso, a differenza di quanto accadeva -con gli esempi elementari del Cap.~\ref{cha:network} si assume che sia il +con gli esempi elementari del Cap.~\capref{cha:network} si assume che sia il client ad effettuare delle richieste a cui il server risponde, il client notifica poi di avere concluso inviando un end-of-file a cui il server risponderà anche lui chiudendo la connessione per aspettarne una nuova. @@ -621,7 +622,7 @@ risponder \end{figure} Useremo questo schema per l'esempio di implementazione del servizio -\texttt{echo} che illustreremo in \ref{sec:TCPel_echo_example}. +\texttt{echo} che illustreremo in \secref{sec:TCPel_echo_example}. \subsection{La funzione \texttt{bind}} @@ -642,7 +643,7 @@ Il prototipo della funzione, definito in \texttt{sys/socket.h}, Il primo argomento è un file descriptor ottenuto da una precedente chiamata a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente l'indirizzo (locale) del socket e la dimensione della struttura che lo - contiene, secondo quanto già trattato in \ref{sec:sock_sockaddr}. + contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}. La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore. La variabile \texttt{errno} viene settata secondo i seguenti @@ -685,7 +686,7 @@ client. Per specificare un indirizzo generico con IPv4 si usa il valore \texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti -è pari a zero, nell'esempio \ref{fig:net_serv_sample} si è usata +è pari a zero, nell'esempio \figref{fig:net_serv_sample} si è usata un'assegnazione immediata del tipo: \begin{verbatim} serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */ @@ -724,7 +725,7 @@ connessione con un server TCP, il prototipo della funzione, definito in Il primo argomento è un file descriptor ottenuto da una precedente chiamata a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente l'indirizzo e la dimensione della struttura che contiene l'indirizzo del - socket, già descritta in \ref{sec:sock_sockaddr}. + socket, già descritta in \secref{sec:sock_sockaddr}. La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore. La variabile \texttt{errno} viene settata secondo i seguenti @@ -755,8 +756,8 @@ connessione con un server TCP, il prototipo della funzione, definito in La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il numero di porta del server a cui ci si vuole connettere, come mostrato -nell'esempio \ref{sec:net_cli_sample} usando le funzioni illustrate in -\ref{sec:sock_addr_func}. +nell'esempio \secref{sec:net_cli_sample} usando le funzioni illustrate in +\secref{sec:sock_addr_func}. Nel caso di socket TCP la funzione \texttt{connect} avvia il three way handshake, e ritorna solo quando la connessione è stabilita o si è verificato @@ -802,7 +803,7 @@ da errori o problemi nella chiamata della funzione sono le seguenti: \end{enumerate} Se si fa riferimento al diagramma degli stati del TCP riportato in -\ref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket +\figref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il