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}
+\begin{enumerate}
\item Il server deve essere preparato per accettare le connessioni in arrivo;
il procedimento si chiama \textsl{apertura passiva} del socket (in inglese
\textit{passive open}); questo viene fatto chiamando la sequenza di funzioni
\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.
\texttt{SYN} del server inviando un \texttt{ACK}. Alla ricezione di
quest'ultimo la funzione \texttt{accept} del server ritorna e la connessione
è stabilita.
-\end{itemize}
+\end{enumerate}
Il procedimento viene chiamato \textit{three way handshake} dato che per
realizzarlo devono essere scambiati tre segmenti. In \nfig\ si è
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}
\item Dopo un certo tempo anche il secondo processo chiamerà la funzione
\texttt{close} sul proprio socket, causando l'emissione di un altro segmento
FIN.
-
+
\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
con un ACK.
\end{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).
-In assenza di connessione lo stato del TCP è \textsl{CLOSED}; quando una
+In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
applicazione esegue una apertura attiva il TCP emette un SYN e lo stato
-diventa \textsl{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
-emette un ACK e passa allo stato \textsl{ESTABLISHED}; questo è lo stato
+diventa \texttt{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
+emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
finale in cui avviene la gran parte del trasferimento dei dati.
Dal lato server in genere invece il passaggio che si opera con l'apertura
-passiva è quello di portare il socket dallo stato \textsl{CLOSED} allo
-stato \textsl{LISTEN} in cui vengono accettate le connessioni.
+passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
+stato \texttt{LISTEN} in cui vengono accettate le connessioni.
-Dallo stato \textsl{ESTABLISHED} si può uscire in due modi; se un'applicazione
+Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
chiama la \texttt{close} prima di aver ricevuto un end of file (chiusura
-attiva) la transizione è verso lo stato \textsl{FIN\_WAIT\_1}; se invece
-l'applicazione riceve un FIN nello stato \textsl{ESTABLISHED} (chiusura
-passiva) la transizione è verso lo stato \textsl{CLOSE\_WAIT}.
+attiva) la transizione è verso lo stato \texttt{FIN\_WAIT\_1}; se invece
+l'applicazione riceve un FIN nello stato \texttt{ESTABLISHED} (chiusura
+passiva) la transizione è verso lo stato \texttt{CLOSE\_WAIT}.
In \nfig\ è riportato lo schema dello scambio dei pacchetti che avviene per
una un esempio di connessione, insieme ai vari stati che il protocollo viene
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.
+\texttt{TIME\_WAIT} su cui torneremo fra poco.
È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
e uno di risposta) il TCP necessiti di ulteriori otto segmenti, se invece si
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
Ogni implementazione del TCP deve scegliere un valore per la MSL (l'RFC1122
raccomanda 2 minuti, linux usa 30 secondi), questo comporta una durata dello
-stato \textsl{TIME\_WAIT} che a seconda delle implementazioni può variare fra
+stato \texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra
1 a 4 minuti.
Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due motivi
principali:
-\begin{itemize}
+\begin{enumerate}
\item implementare in maniera affidabile la terminazione della connessione
in entrambe le direzioni.
\item consentire l'eliminazione dei segmenti duplicati dalla rete.
-\end{itemize}
+\end{enumerate}
Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
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 prototipo della funzione, definito in \texttt{sys/socket.h}, è il seguente:
-\begin{itemize}
-\item \texttt{int bind(int sockfd, const struct sockaddr *serv\_addr,
+\begin{prototype}{int bind(int sockfd, const struct sockaddr *serv\_addr,
socklen\_t addrlen) }
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
codici di errore:
- \begin{itemize}
+ \begin{errlist}
\item \texttt{EBADF} Il file descriptor non è valido.
\item \texttt{EINVAL} Il socket ha già un indirizzo assegnato.
\item \texttt{ENOTSOCK} Il file descriptor non è associato ad un socket.
\item \texttt{EACCESS} Si è cercato di usare un indirizzo riservato senza
essere root.
- \end{itemize}
-
-\end{itemize}
+ \end{errlist}
+\end{prototype}
Con il TCP la chiamata \texttt{bind} permette di specificare l'indirizzo, la
porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
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 */
connessione con un server TCP, il prototipo della funzione, definito in
\texttt{sys/socket.h}, è il seguente:
-\begin{itemize}
-\item \texttt{int connect(int sockfd, const struct sockaddr *serv\_addr,
+\begin{prototype}{int connect(int sockfd, const struct sockaddr *serv\_addr,
socklen\_t addrlen) }
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
codici di errore:
- \begin{itemize}
+ \begin{errlist}
\item \texttt{EBADF} Il file descriptor non è valido.
\item \texttt{EFAULT} L'indirizzo della struttura di indirizzi è al di fuori
dello spazio di indirizzi dell'utente.
\item \texttt{EACCESS, EPERM} Si è tentato di eseguire una connessione ad un
indirizzo broacast senza che il socket fosse stato abilitato per il
broadcast.
- \end{itemize}
-\end{itemize}
+ \end{errlist}
+\end{prototype}
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