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
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;
\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.
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
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}
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}
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).
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.
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
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
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
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.
\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}}
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
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 */
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
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
\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
projects / gapil.git / blobdiff