ci sono una serie di flag usati per gestire la connessione, come SYN, ACK,
URG, FIN, alcuni di essi, come SYN (che sta per \textit{syncronize})
corrispondono a funzioni particolari del protocollo e danno il nome al
- segmento, (per maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).} di
+ segmento, (per maggiori dettagli si veda sez.~\ref{sec:tcp_protocol}).} di
dati che vengono scambiati) che porta alla creazione di una connessione è la
seguente:
-\begin{enumerate}
+\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
funzione \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN
del server inviando un ACK. Alla ricezione di quest'ultimo la funzione
\func{accept} del server ritorna e la connessione è stabilita.
-\end{enumerate}
+\end{enumerate*}
Il procedimento viene chiamato \textit{three way handshake} dato che per
realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
Si è accennato in precedenza ai \textsl{numeri di sequenza}, che sono anche
riportati in fig.~\ref{fig:TCP_TWH}: per gestire una connessione affidabile
-infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
-bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
+infatti il protocollo TCP prevede nell'intestazione la presenza di un numero a
+32 bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
nella sequenza del flusso corrisponde il primo byte della sezione dati
contenuta nel segmento.
all'inizio della connessione e trasmesso con il SYN;
l'\textit{acknowledgement} di ciascun segmento viene effettuato dall'altro
capo della connessione impostando il flag ACK e restituendo nell'apposito
-campo dell'header un \textit{acknowledge number}) pari al numero di sequenza
-che il ricevente si aspetta di ricevere con il pacchetto successivo; dato che
-il primo pacchetto SYN consuma un byte, nel \textit{three way handshake} il
-numero di \textit{acknowledge} è sempre pari al numero di sequenza iniziale
-incrementato di uno; lo stesso varrà anche (vedi fig.~\ref{fig:TCP_close}) per
-l'\textit{acknowledgement} di un segmento FIN.
+campo dell'intestazione un \textit{acknowledge number}) pari al numero di
+sequenza che il ricevente si aspetta di ricevere con il pacchetto successivo;
+dato che il primo pacchetto SYN consuma un byte, nel \textit{three way
+ handshake} il numero di \textit{acknowledge} è sempre pari al numero di
+sequenza iniziale incrementato di uno; lo stesso varrà anche (vedi
+fig.~\ref{fig:TCP_close}) per l'\textit{acknowledgement} di un segmento FIN.
\index{numeri~di~sequenza|)}
\itindend{three~way~handshake}
Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
le cosiddette \textit{TCP options}, da non confondere con le opzioni dei
-socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}; in questo
+socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}. In questo
caso infatti si tratta delle opzioni che vengono trasmesse come parte di un
pacchetto TCP, e non delle funzioni che consentono di impostare i relativi
valori. Queste opzioni vengono inserite fra l'intestazione ed i dati, e
servono a comunicare all'altro capo una serie di parametri utili a regolare la
-connessione. Normalmente vengono usate le seguenti opzioni:
+connessione. Normalmente vengono usate le seguenti opzioni:
-\begin{itemize}
+\begin{itemize*}
\item \textit{MSS option}, con questa opzione ciascun capo della connessione
annuncia all'altro il massimo ammontare di dati (MMS sta appunto per
\textit{Maximum Segment Size}, vedi sez.~\ref{sec:tcp_protocol}) che
poter ottenere il massimo dalla trasmissione.
Per questo esiste un'altra opzione che indica un fattore di scala da
- applicare al valore della finestra annunciata per la connessione corrente
- (espresso come numero di bit cui spostare a sinistra il valore della
- finestra annunciata inserito nel pacchetto). Essendo una nuova opzione per
+ applicare al valore della finestra annunciata per la connessione corrente,
+ espresso come numero di bit cui spostare a sinistra il valore della
+ finestra annunciata inserito nel pacchetto. Essendo una nuova opzione per
garantire la compatibilità con delle vecchie realizzazione del protocollo la
procedura che la attiva prevede come negoziazione che l'altro capo della
connessione riconosca esplicitamente l'opzione inserendola anche lui nel suo
per le connessioni ad alta velocità per evitare possibili corruzioni di dati
dovute a pacchetti perduti che riappaiono; anche questa viene negoziata
all'inizio della connessione come la precedente.
-
-\end{itemize}
+\end{itemize*}
La \textit{MSS option} è generalmente supportata da quasi tutte le
realizzazioni del protocollo, le ultime due opzioni (trattate
segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
caso la successione degli eventi è la seguente:
-\begin{enumerate}
+\begin{enumerate*}
\item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
\textit{active close}). Questo comporta l'emissione di un segmento FIN, che
\item L'altro capo della connessione riceverà il segmento FIN conclusivo e
risponderà con un ACK.
-\end{enumerate}
+\end{enumerate*}
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro. Questo non è vero sempre
essere due volte la \textit{Maximum Segment Lifetime} (da qui in avanti
abbreviata in MSL).
-La MSL è la stima del massimo periodo di tempo in secondi che un pacchetto IP
-può vivere 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'intestazione di IP (per maggiori dettagli vedi
+La \textit{Maximum Segment Lifetime} è la stima del massimo periodo di tempo
+in secondi che un pacchetto IP può vivere 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'intestazione di IP (per maggiori dettagli vedi
sez.~\ref{sec:ip_protocol}), 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 ``\textsl{salti}'' è di 255, pertanto anche se il
TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
sua base si può stimare che un pacchetto IP non possa restare nella rete per
-più un certo numero di secondi, che costituisce la \textit{Maximum Segment
- Lifetime}.
+più un certo numero di secondi, che costituisce la MSL.
Ogni realizzazione del TCP deve scegliere un valore per la MSL;
l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
-per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
-tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
-nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
-sicuri che lo stesso avvenga per le risposte nella direzione opposta.
+per un periodo di 2 volte la MSL, prima per attendere MSL secondi per essere
+sicuri che tutti i pacchetti duplicati in arrivo siano stati ricevuti e
+scartati, o che nel frattempo siano stati eliminati dalla rete, poi altri MSL
+secondi per essere sicuri che lo stesso avvenga per le risposte nella
+direzione opposta.
In questo modo, prima che venga creata una nuova connessione, il protocollo
TCP si assicura che tutti gli eventuali segmenti residui di una precedente
\cmd{netstat} permette di visualizzare queste informazioni nei campi
\textit{Local Address} e \textit{Foreing Address}.
-
-\subsection{Le porte ed il modello client/server}
-\label{sec:TCP_port_cliserv}
-
Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
che fare con un'applicazione client/server (come quelle che descriveremo in
sez.~\ref{sec:TCP_daytime_application} e sez.~\ref{sec:TCP_echo_application})
In questa sezione descriveremo in maggior dettaglio le varie funzioni che
vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
-precedente in sez.~\ref{sec:sock_creation}.
+precedente in sez.~\ref{sec:sock_creation}. Pur trattandole principalmente dal
+punto di vista dei socket TCP, daremo brevemente conto del loro comportamento
+anche per altri tipi di socket.
\subsection{La funzione \func{bind}}
\begin{errlist}
\item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
sufficienti privilegi.
- \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
+ \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo
+ richiesto oppure quando non si è richiesta un porta specifica per avere
+ una porta effimera non ve ne sono di disponibili nell'intervallo ad esse
+ riservato correntemente in uso.
\item[\errcode{EBADF}] il file descriptor non è valido.
- \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
+ \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato,
+ o \param{addrlen} è sbagliata, o \param{serv\_addr} non è valido per il
+ dominio.
\item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
\end{errlist}
- ed \errval{EFAULT} nel suo significato generico, inoltre per i socket di
+ ed \errval{EFAULT} nel suo significato generico; inoltre per i socket di
tipo \const{AF\_UNIX}:
\begin{errlist}
\item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
disponibile.
\end{errlist}
- ed \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
+ ed \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
\errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.}
\end{funcproto}
\label{sec:TCP_func_connect}
La funzione \funcd{connect} è usata da un client TCP per stabilire la
-connessione con un server TCP,\footnote{di nuovo la funzione è generica e
- supporta vari tipi di socket, la differenza è che per socket senza
- connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si
- limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
- e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
- \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
- TCP il \textit{three way handshake}) della connessione.} il prototipo della
-funzione è il seguente:
+connessione con un server TCP, ma la funzione è generica e supporta vari tipi
+di socket. La differenza è che per socket senza connessione come quelli di
+tipo \const{SOCK\_DGRAM} la sua chiamata si limiterà ad impostare l'indirizzo
+dal quale e verso il quale saranno inviati e ricevuti i pacchetti, mentre per
+socket di tipo \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET} essa attiverà
+la procedura di avvio della connessione (nel caso del TCP il \textit{three way
+ handshake}). Il suo prototipo è il seguente:
\begin{funcproto}{
projects / gapil.git / commitdiff