%% tcpsock.tex
%%
-%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{I socket TCP}
\label{cha:TCP_socket}
\subsection{Le opzioni TCP.}
\label{sec:TCP_TCP_opt}
-Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP
-(le cosiddette \textit{TCP options}, che vengono inserite fra l'header e i
-dati) che servono a comunicare all'altro capo una serie di parametri utili a
-regolare la connessione. Normalmente vengono usate le seguenti opzioni:
+Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
+le cosiddette \textit{TCP options},\footnote{da non confondere con le opzioni
+ dei socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}, in
+ questo caso si tratta delle opzioni che vengono trasmesse come parte di un
+ pacchetto TCP, non delle funzioni che consentono di impostare i relativi
+ valori.} che vengono inserite fra l'header e i dati, e che servono a
+comunicare all'altro capo una serie di parametri utili a regolare la
+connessione. Normalmente vengono usate le seguenti opzioni:
\begin{itemize}
-\item \textit{MSS option}, dove MMS sta per \textit{maximum segment size}, con
- questa opzione ciascun capo della connessione annuncia all'altro il massimo
- ammontare di dati che vorrebbe accettare per ciascun segmento nella
- connessione corrente. È possibile leggere e scrivere questo valore
- attraverso l'opzione del socket \const{TCP\_MAXSEG}.
+\item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
+ \textit{Maximum Segment Size}, con questa opzione ciascun capo della
+ connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
+ accettare per ciascun segmento nella connessione corrente. È possibile
+ leggere e scrivere questo valore attraverso l'opzione del socket
+ \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}).
-\item \textit{window scale
- option}, %come spiegato in sez.~\ref{sec: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
- memoria per i dati. Questo è un numero a 16 bit dell'header, che così può
- indicare un massimo di 65535 byte;\footnote{ Linux usa come massimo 32767
- per evitare problemi con alcune implementazioni che usano l'aritmetica con
- segno per implementare lo stack TCP.} ma alcuni tipi di connessione come
- quelle ad alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi
- ritardi nel cammino dei pacchetti (come i satelliti) richiedono una finestra
- più grande per poter ottenere il massimo dalla trasmissione, per questo
- esiste questa opzione che indica un fattore di scala da applicare al valore
- della finestra annunciata\footnote{essendo una nuova opzione per garantire
- la compatibilità con delle vecchie implementazioni 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 SYN di risposta dell'apertura della connessione.} per la connessione
- corrente (espresso come numero di bit cui spostare a sinistra il valore
- della finestra annunciata inserito nel pacchetto).
+\item \textit{window scale option}, il protocollo TCP implementa il controllo
+ di flusso attraverso una \itindex{advertised~window} \textit{advertised
+ window} (la ``\textsl{finestra annunciata}'', vedi
+ sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun capo della
+ comunicazione dichiara quanto spazio disponibile ha in memoria per i dati.
+ Questo è un numero a 16 bit dell'header, che così può indicare un massimo di
+ 65535 byte;\footnote{Linux usa come massimo 32767 per evitare problemi con
+ alcune implementazioni che usano l'aritmetica con segno per implementare
+ lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità
+ (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel cammino dei
+ pacchetti (come i satelliti) richiedono una finestra più grande per poter
+ ottenere il massimo dalla trasmissione. Per questo esiste questa opzione che
+ indica un fattore di scala da applicare al valore della
+ \itindex{advertised~window} finestra annunciata\footnote{essendo una nuova
+ opzione per garantire la compatibilità con delle vecchie implementazioni
+ 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 SYN di risposta dell'apertura della
+ connessione.} per la connessione corrente (espresso come numero di bit cui
+ spostare a sinistra il valore della finestra annunciata inserito nel
+ pacchetto). Con Linux è possibile indicare al kernel di far negoziare il
+ fattore di scala in fase di creazione di una connessione tramite la
+ \textit{sysctl} \texttt{tcp\_window\_scaling} (vedi
+ sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
+ funzionalità è comunque necessario ampliare le dimensioni dei buffer di
+ ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
+ con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl}) che
+ a livello di singoli socket con le relative opzioni (vedi
+ sez.~\ref{sec:sock_tcp_udp_options}).}
\item \textit{timestamp option}, è anche questa una nuova opzione necessaria
per le connessioni ad alta velocità per evitare possibili corruzioni di dati
\end{itemize}
-La MSS è generalmente supportata da quasi tutte le implementazioni del
-protocollo, le ultime due opzioni (trattate
+La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
+le implementazioni del protocollo, le ultime due opzioni (trattate
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
vengono anche dette \textit{long fat pipe options} dato che questo è il nome
che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
\label{fig:TCP_conn_example}
\end{figure}
-La connessione viene iniziata dal client che annuncia un MSS di 1460, un
-valore tipico con Linux per IPv4 su Ethernet, il server risponde con lo stesso
-valore (ma potrebbe essere anche un valore diverso).
+La connessione viene iniziata dal client che annuncia una
+\itindex{Maximum~Segment~Size} MSS di 1460, un valore tipico con Linux per
+IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe essere
+anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
internet (una versione aggiornata si può trovare all'indirizzo
-\href{ftp://ftp.isi.edu/in-notes/iana/assignements/port-number}
-{\texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}}); inoltre
-in un sistema unix-like un analogo elenco viene mantenuto nel file
-\file{/etc/services}, con la corrispondenza fra i vari numeri di porta ed il
-nome simbolico del servizio. I numeri sono divisi in tre intervalli:
+\href{http://www.iana.org/assignments/port-numbers}
+{\texttt{http://www.iana.org/assignments/port-numbers}}); inoltre in un
+sistema unix-like un analogo elenco viene mantenuto nel file
+\conffile{/etc/services}, con la corrispondenza fra i vari numeri di porta ed
+il nome simbolico del servizio. I numeri sono divisi in tre intervalli:
\begin{enumerate*}
\item \textsl{le porte note}. I numeri da 0 a 1023. Queste sono controllate e
demone che deve essere contattato dai client per ottenere la porta effimera
su cui si trova il server.} che in genere viene identificato dalla porta su
cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
-\file{/etc/services}).
+\conffile{/etc/services}).
Con \func{bind} si può assegnare un indirizzo IP specifico ad un socket,
purché questo appartenga ad una interfaccia della macchina. Per un client TCP
\const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
inutile. Si tenga presente comunque che tutte le costanti \val{INADDR\_}
(riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-l'\textit{endianess}\itindex{endianess} della macchina, ed anche se
-esse possono essere invarianti rispetto all'ordinamento dei bit, è comunque
-buona norma usare sempre la funzione \func{htonl}.
+\itindex{endianess} l'\textit{endianess} della macchina, ed anche se esse
+possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
+norma usare sempre la funzione \func{htonl}.
\begin{table}[htb]
\centering
\hline
\hline
\const{INADDR\_ANY} & Indirizzo generico (\texttt{0.0.0.0})\\
- \const{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\
+ \const{INADDR\_BROADCAST}& Indirizzo di \itindex{broadcast}
+ \textit{broadcast}.\\
\const{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback}
(\texttt{127.0.0.1}).\\
\const{INADDR\_NONE} & Indirizzo errato.\\
staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
-
\subsection{La funzione \func{connect}}
\label{sec:TCP_func_connect}
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 \itindex{three~way~handshake}\textit{three way handshake}) della
+ TCP il \itindex{three~way~handshake} \textit{three way handshake}) della
connessione.} il prototipo della funzione è il seguente:
\begin{prototype}{sys/socket.h}
{int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t
\item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
corretta nel relativo campo.
\item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
- connessione ad un indirizzo broadcast senza che il socket fosse stato
- abilitato per il broadcast.
+ connessione ad un indirizzo \itindex{broadcast} \textit{broadcast} senza
+ che il socket fosse stato abilitato per il \itindex{broadcast}
+ \textit{broadcast}.
\end{errlist}
altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
\errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
in sez.~\ref{sec:sock_addr_func}.
Nel caso di socket TCP la funzione \func{connect} avvia il
-\itindex{three~way~handshake}\textit{three way handshake}, e ritorna
-solo quando la connessione è stabilita o si è verificato un errore. Le
-possibili cause di errore sono molteplici (ed i relativi codici riportati
-sopra), quelle che però dipendono dalla situazione della rete e non da errori
-o problemi nella chiamata della funzione sono le seguenti:
+\itindex{three~way~handshake} \textit{three way handshake}, e ritorna solo
+quando la connessione è stabilita o si è verificato un errore. Le possibili
+cause di errore sono molteplici (ed i relativi codici riportati sopra), quelle
+che però dipendono dalla situazione della rete e non da errori o problemi
+nella chiamata della funzione sono le seguenti:
\begin{enumerate}
\item Il client non riceve risposta al SYN: l'errore restituito è
- \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata
- di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24 secondi, se
- dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux
- invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero
- di volte che può essere stabilito dall'utente sia con una opportuna
- \func{sysctl} che attraverso il filesystem \file{/proc} scrivendo il valore
- voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito
- per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo
- circa 180 secondi.
+ \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla
+ chiamata di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24
+ secondi, se dopo 75 secondi non ha ricevuto risposta viene ritornato
+ l'errore. Linux invece ripete l'emissione del SYN ad intervalli di 30
+ secondi per un numero di volte che può essere stabilito dall'utente. Questo
+ può essere fatto a livello globale con una opportuna
+ \func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in
+ \procfile{/proc/sys/net/ipv4/tcp\_syn\_retries}, vedi
+ sez.~\ref{sec:sock_ipv4_sysctl}.} e a livello di singolo socket con
+ l'opzione \const{TCP\_SYNCNT} (vedi sez.~\ref{sec:sock_tcp_udp_options}). Il
+ valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
+ un timeout dopo circa 180 secondi.
\item Il client riceve come risposta al SYN un RST significa che non c'è
nessun programma in ascolto per la connessione sulla porta specificata (il
infatti vengono mantenute due code:
\begin{enumerate}
\item La coda delle connessioni incomplete (\textit{incomplete connection
- queue} che contiene un riferimento per ciascun socket per il quale è
- arrivato un SYN ma il \itindex{three~way~handshake}\textit{three way
+ queue}) che contiene un riferimento per ciascun socket per il quale è
+ arrivato un SYN ma il \itindex{three~way~handshake} \textit{three way
handshake} non si è ancora concluso. Questi socket sono tutti nello stato
\texttt{SYN\_RECV}.
-\item La coda delle connessioni complete (\textit{complete connection queue}
- che contiene un ingresso per ciascun socket per il quale il \textit{three
- way handshake} è stato completato ma ancora \func{accept} non è ritornata.
- Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
+\item La coda delle connessioni complete (\textit{complete connection queue})
+ che contiene un ingresso per ciascun socket per il quale il
+ \itindex{three~way~handshake} \textit{three way handshake} è stato
+ completato ma ancora \func{accept} non è ritornata. Questi socket sono
+ tutti nello stato \texttt{ESTABLISHED}.
\end{enumerate}
Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
client o fino ad un timeout. Nel caso di completamento del
-\itindex{three~way~handshake}\textit{three way handshake} la voce viene
+\itindex{three~way~handshake} \textit{three way handshake} la voce viene
spostata nella coda delle connessioni complete. Quando il processo chiama la
funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept}) la prima voce
nella coda delle connessioni complete è passata al programma, o, se la coda è
della coda delle connessioni incomplete può essere ancora controllata usando
la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
o scrivendola direttamente in
-\file{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
+\procfile{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
protezione dei syncookies però (con l'opzione da compilare nel kernel e da
-attivare usando \file{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore viene
-ignorato e non esiste più un valore massimo. In ogni caso in Linux il valore
-di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se è
-superiore a detta costante (che di default vale 128).
+attivare usando \procfile{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
+viene ignorato e non esiste più un valore massimo. In ogni caso in Linux il
+valore di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se
+è superiore a detta costante (che di default vale 128).\footnote{il valore di
+ questa costante può essere controllato con un altro parametro di
+ \func{sysctl}, vedi sez.~\ref{sec:sock_ioctl_IP}.}
La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
kernel non supportavano neanche valori superiori, ma la situazione corrente è
server è occupato fra chiamate successive alla \func{accept} (per cui la coda
più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
di gestire la presenza di un gran numero di SYN in attesa di concludere il
-\textit{three way handshake}\itindex{three~way~handshake}.
+\itindex{three~way~handshake} \textit{three way handshake}.
Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
programma.
-Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
-ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
-\func{listen} che dice al kernel di accettare connessioni per il socket che
-abbiamo creato; la funzione indica inoltre, con il secondo argomento, il
-numero massimo di connessioni che il kernel accetterà di mettere in coda per
-il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
-un messaggio, e si esce (\texttt{\small 38}) immediatamente.
+Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{in
+ ascolto}'' il socket; questo viene fatto (\texttt{\small 36}) con la
+funzione \func{listen} che dice al kernel di accettare connessioni per il
+socket che abbiamo creato; la funzione indica inoltre, con il secondo
+argomento, il numero massimo di connessioni che il kernel accetterà di mettere
+in coda per il suddetto socket. Di nuovo in caso di errore si stampa
+(\texttt{\small 37}) un messaggio, e si esce (\texttt{\small 38})
+immediatamente.
La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
(che viene chiamato anche \textit{listening descriptor}) a questo punto si può
\textit{three way handshake} la connessione è stabilita; la \func{connect}
ritornerà nel client\footnote{si noti che è sempre la \func{connect} del
client a ritornare per prima, in quanto questo avviene alla ricezione del
- secondo segmento (l'ACK del server) del \textit{three way handshake}, la
- \func{accept} del server ritorna solo dopo un altro mezzo RTT quando il
- terzo segmento (l'ACK del client) viene ricevuto.} e la \func{accept} nel
-server, ed usando di nuovo \cmd{netstat} otterremmo che:
+ secondo segmento (l'ACK del server) del \itindex{three~way~handshake}
+ \textit{three way handshake}, la \func{accept} del server ritorna solo dopo
+ un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene
+ ricevuto.} e la \func{accept} nel server, ed usando di nuovo \cmd{netstat}
+otterremmo che:
\begin{verbatim}
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
gestore e che l'azione predefinita per questo segnale è quella di essere
ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di zombie\index{zombie}
+otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
ripetendo il comando \cmd{ps}:
\begin{verbatim}
2359 pts/0 Z 0:00 [echod <defunct>]
\end{verbatim}
-Dato che non è il caso di lasciare processi zombie\index{zombie}, occorrerà
+Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
ricevere opportunamente lo stato di terminazione del processo (si veda
sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al nostro
con dei server molto occupati. In tal caso, con una struttura del server
simile a quella del nostro esempio, in cui la gestione delle singole
connessioni è demandata a processi figli, può accadere che il \textit{three
- way handshake}\itindex{three~way~handshake} venga completato e la relativa
+ way handshake} \itindex{three~way~handshake} venga completato e la relativa
connessione abortita subito dopo, prima che il padre, per via del carico della
macchina, abbia fatto in tempo ad eseguire la chiamata ad \func{accept}. Di
nuovo si ha una situazione analoga a quella illustrata in
\end{verbatim}
Le prime tre righe vengono prodotte al momento in cui lanciamo il nostro
-client, e corrispondono ai tre pacchetti del
-\itindex{three~way~handshake}\textit{three way handshake}. L'output del
-comando riporta anche i numeri di sequenza iniziali, mentre la lettera
-\texttt{S} indica che per quel pacchetto si aveva il SYN flag attivo. Si noti
-come a partire dal secondo pacchetto sia sempre attivo il campo \texttt{ack},
-seguito dal numero di sequenza per il quale si da il ricevuto; quest'ultimo, a
-partire dal terzo pacchetto, viene espresso in forma relativa per maggiore
-compattezza. Il campo \texttt{win} in ogni riga indica la \textit{advertising
- window} di cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può
-verificare dall'output del comando come venga appunto realizzata la sequenza
-di pacchetti descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal
-client un primo pacchetto con il SYN che inizia la connessione, a cui il
-server risponde dando il ricevuto con un secondo pacchetto, che a sua volta
-porta un SYN, cui il client risponde con un il terzo pacchetto di ricevuto.
+client, e corrispondono ai tre pacchetti del \itindex{three~way~handshake}
+\textit{three way handshake}. L'output del comando riporta anche i numeri di
+sequenza iniziali, mentre la lettera \texttt{S} indica che per quel pacchetto
+si aveva il SYN flag attivo. Si noti come a partire dal secondo pacchetto sia
+sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il
+quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene
+espresso in forma relativa per maggiore compattezza. Il campo \texttt{win} in
+ogni riga indica la \itindex{advertised~window} \textit{advertised window} di
+cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare
+dall'output del comando come venga appunto realizzata la sequenza di pacchetti
+descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un
+primo pacchetto con il SYN che inizia la connessione, a cui il server risponde
+dando il ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui
+il client risponde con un il terzo pacchetto di ricevuto.
Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe
-del \textit{three way handshake}\itindex{three~way~handshake} non avremo nulla
-fin tanto che non scriveremo una prima riga sul client; al momento in cui
-facciamo questo si genera una sequenza di altri quattro pacchetti. Il primo,
-dal client al server, contraddistinto da una lettera \texttt{P} che significa
-che il flag PSH è impostato, contiene la nostra riga (che è appunto di 11
-caratteri), e ad esso il server risponde immediatamente con un pacchetto vuoto
-di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
+del \itindex{three~way~handshake} \textit{three way handshake} non avremo
+nulla fin tanto che non scriveremo una prima riga sul client; al momento in
+cui facciamo questo si genera una sequenza di altri quattro pacchetti. Il
+primo, dal client al server, contraddistinto da una lettera \texttt{P} che
+significa che il flag PSH è impostato, contiene la nostra riga (che è appunto
+di 11 caratteri), e ad esso il server risponde immediatamente con un pacchetto
+vuoto di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso
contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto
pacchetto. Questo causerà la ricezione dell'eco nel client che lo stamperà a
In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso
di prima. Solo che stavolta, non appena inviata la seconda riga, il programma
-si bloccherà nella successiva chiamata a \func{read}, non ottendo nessuna
+si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna
risposta. Quello che succede è che nel frattempo il kernel provvede, come
richiesto dal protocollo TCP, a tentare la ritrasmissione della nostra riga un
certo numero di volte, con tempi di attesa crescente fra un tentativo ed il
Il risultato finale qui dipende dall'implementazione dello stack TCP, e nel
caso di Linux anche dall'impostazione di alcuni dei parametri di sistema che
si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
-in questo caso in particolare da \file{tcp\_retries2} (vedi
-sez.~\ref{sec:sock_sysctl}). Questo parametro infatti specifica il numero di
-volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo di
-una connessione prima di riportare un errore di timeout. Il valore
+in questo caso in particolare da
+\procrelfile{/proc/sys/net/ipv4}{tcp\_retries2} (vedi
+sez.~\ref{sec:sock_ipv4_sysctl}). Questo parametro infatti specifica il numero
+di volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo
+di una connessione prima di riportare un errore di timeout. Il valore
preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione,
ma nel nostro caso le cose sono andate diversamente, dato che le
ritrasmissioni registrate da \cmd{tcpdump} sono solo 8; inoltre l'errore
che si incarica di trovare le corrispondenze fra indirizzo IP e indirizzo
hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
- cache}\footnote{la \textit{ARP chache} è una tabella mantenuta internamente
+ cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente
dal kernel che contiene tutte le corrispondenze fra indirizzi IP e indirizzi
fisici, ottenute appunto attraverso il protocollo ARP; le voci della tabella
hanno un tempo di vita limitato, passato il quale scadono e devono essere
sez.~\ref{sec:sock_generic_options}) che provvede all'esecuzione di questo
controllo.
+
\section{L'uso dell'I/O multiplexing}
\label{sec:TCP_sock_multiplexing}
sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
sotto controllo è pronto per la relativa operazione.
+
+
In quell'occasione non abbiamo però definito cosa si intende per pronto,
infatti per dei normali file, o anche per delle pipe, la condizione di essere
pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
dei socket, visto che possono intervenire tutte una serie di possibili
condizioni di errore dovute alla rete. Occorre allora specificare chiaramente
quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}''
-quando viene passato come membro di uno dei tre \textit{file descriptor set}
-usati da \func{select}.
+quando viene passato come membro di uno dei tre \itindex{file~descriptor~set}
+\textit{file descriptor set} usati da \func{select}.
Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
che un socket (che sarà riportato nel primo insieme di file descriptor) è
non si bloccherà ma restituirà una condizione di errore (ad esempio
\func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
valore. Vedremo in sez.~\ref{sec:sock_generic_options} come sia possibile
- estrarre e cancellare errori pendenti su un socket usando l'opzione
- \const{SO\_ERROR}.
+ estrarre e cancellare gli errori pendenti su un socket senza usare
+ \func{read} usando l'opzione \const{SO\_ERROR}.
\item quando si sta utilizzando un \textit{listening socket} ed ci sono delle
connessioni completate. In questo caso la funzione \func{accept} non si
bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
-condizione di eccezione pendente, e cioè la ricezione sul socket di dati
-\textsl{fuori banda} (o \textit{out-of-band}), una caratteristica specifica
-dei socket TCP su cui torneremo in sez.~\ref{sec:TCP_urgent_data}.
+condizione di eccezione pendente, e cioè la ricezione sul socket di
+\textsl{dati urgenti} (o \itindex{out-of-band} \textit{out-of-band}), una
+caratteristica specifica dei socket TCP su cui torneremo in
+sez.~\ref{sec:TCP_urgent_data}.
Si noti come nel caso della lettura \func{select} si applichi anche ad
operazioni che non hanno nulla a che fare con l'I/O di dati come il
possono utilizzare questi valori per far si che \func{select} ritorni solo
quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
controllo è utile di norma solo per la lettura, in quanto in genere le
- operazioni di scrittura sono già controllate dall'applicazione, che sà
+ operazioni di scrittura sono già controllate dall'applicazione, che sa
sempre quanti dati invia, mentre non è detto possa conoscere la quantità di
dati in ricezione; per cui, nella situazione in cui si conosce almeno un
valore minimo, per evitare la penalizzazione dovuta alla ripetizione delle
operazioni di lettura per accumulare dati sufficienti, si può lasciare al
- kernel il compito di impostare un minimo al di sotto del quale il file
- descriptor, pur avendo disponibili dei dati, non viene dato per pronto in
- lettura.}
+ kernel il compito di impostare un minimo al di sotto del quale il socket,
+ pur avendo disponibili dei dati, non viene dato per pronto in lettura.}
allegati alla guida.
In questo caso la funzione comincia (\texttt{\small 8--9}) con l'azzeramento
-del file descriptor set \var{fset} e l'impostazione del valore \var{maxfd}, da
-passare a \func{select} come massimo per il numero di file descriptor. Per
-determinare quest'ultimo si usa la macro \code{max} definita nel nostro file
-\file{macro.h} che raccoglie una collezione di macro di preprocessore di varia
-utilità.
+del \itindex{file~descriptor~set} \textit{file descriptor set} \var{fset} e
+l'impostazione del valore \var{maxfd}, da passare a \func{select} come massimo
+per il numero di file descriptor. Per determinare quest'ultimo si usa la macro
+\code{max} definita nel nostro file \file{macro.h} che raccoglie una
+collezione di macro di preprocessore di varia utilità.
La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
-(\texttt{\small 11--12}) il file descriptor set, impostando i valori per il
-file descriptor associato al socket \var{socket} e per lo standard input (il
-cui valore si recupera con la funzione \func{fileno}). Questo è necessario in
-quanto la successiva (\texttt{\small 13}) chiamata a \func{select} comporta
-una modifica dei due bit relativi, che quindi devono essere reimpostati
-all'inizio di ogni ciclo.
+(\texttt{\small 11--12}) il \itindex{file~descriptor~set} \textit{file
+ descriptor set}, impostando i valori per il file descriptor associato al
+socket \var{socket} e per lo standard input (il cui valore si recupera con la
+funzione \func{fileno}). Questo è necessario in quanto la successiva
+(\texttt{\small 13}) chiamata a \func{select} comporta una modifica dei due
+bit relativi, che quindi devono essere reimpostati all'inizio di ogni ciclo.
Si noti come la chiamata a \func{select} venga eseguita usando come primo
argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
-il solo file descriptor set per il controllo dell'attività in lettura, negli
-altri argomenti sono passati tutti puntatori nulli, non interessando né il
-controllo delle altre attività, né l'impostazione di un valore di timeout.
+il solo \itindex{file~descriptor~set} \textit{file descriptor set} per il
+controllo dell'attività in lettura, negli altri argomenti sono passati tutti
+puntatori nulli, non interessando né il controllo delle altre attività, né
+l'impostazione di un valore di timeout.
Al ritorno di \func{select} si provvede a controllare quale dei due file
descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
di processo, questo tempo è quello impiegato nella trasmissione via rete, che
-viene detto RTT (dalla denominazione inglese \textit{Round Trip Time}) ed è
-quello che viene stimato con l'uso del comando \cmd{ping}.
+viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time}
+\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
+\cmd{ping}.
A questo punto, se torniamo al codice mostrato in
fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
prima (\texttt{\small 19}) si imposta opportunamente \var{eof} ad un valore
non nullo, dopo di che (\texttt{\small 20}) si effettua la chiusura del lato
in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si
-usa la macro \macro{FD\_CLR} per togliere lo standard input dal file
-descriptor set.
+usa la macro \macro{FD\_CLR} per togliere lo standard input dal
+\itindex{file~descriptor~set} \textit{file descriptor set}.
In questo modo anche se la lettura del file in ingresso è conclusa, la
funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
La prima sezione (\texttt{\small 7--10}) del ciclo principale esegue la
-costruzione del \textit{file descriptor set} \var{fset} in base ai socket
-connessi in un certo momento; all'inizio ci sarà soltanto il socket in
-ascolto, ma nel prosieguo delle operazioni, verranno utilizzati anche tutti i
-socket connessi registrati nella tabella \var{fd\_open}. Dato che la chiamata
-di \func{select} modifica il valore del \textit{file descriptor set}, è
-necessario ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi
-procedere con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket
-trovati attivi.
+costruzione del \itindex{file~descriptor~set} \textit{file descriptor set}
+\var{fset} in base ai socket connessi in un certo momento; all'inizio ci sarà
+soltanto il socket in ascolto, ma nel prosieguo delle operazioni, verranno
+utilizzati anche tutti i socket connessi registrati nella tabella
+\var{fd\_open}. Dato che la chiamata di \func{select} modifica il valore del
+\itindex{file~descriptor~set} \textit{file descriptor set}, è necessario
+ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi procedere
+con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket trovati
+attivi.
Per far questo si usa la caratteristica dei file descriptor, descritta in
sez.~\ref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file
(\texttt{\small 29--55}) fintanto che il numero di socket attivi \var{n} resta
diverso da zero; in questo modo se l'unico socket con attività era quello
connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
-saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del file
-descriptor set con i nuovi valori nella tabella) alla chiamata di
-\func{accept}. Se il socket attivo non è quello in ascolto, o ce ne sono
-comunque anche altri, il valore di \var{n} non sarà nullo ed il controllo sarà
-eseguito. Prima di entrare nel ciclo comunque si inizializza (\texttt{\small
- 28}) il valore della variabile \var{i} che useremo come indice nella tabella
-\var{fd\_open} al valore minimo, corrispondente al file descriptor del socket
-in ascolto.
+saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
+\itindex{file~descriptor~set} \textit{file descriptor set} con i nuovi valori
+nella tabella) alla chiamata di \func{accept}. Se il socket attivo non è
+quello in ascolto, o ce ne sono comunque anche altri, il valore di \var{n} non
+sarà nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque
+si inizializza (\texttt{\small 28}) il valore della variabile \var{i} che
+useremo come indice nella tabella \var{fd\_open} al valore minimo,
+corrispondente al file descriptor del socket in ascolto.
Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
dell'indice \var{i} per posizionarsi sul primo valore possibile per un file
disponibilità.
Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo
-\textit{Denial of Service}. Il problema è che in caso di blocco di una
-qualunque delle funzioni di I/O, non avendo usato processi separati, tutto il
-server si ferma e non risponde più a nessuna richiesta. Abbiamo scongiurato
-questa evenienza per l'I/O in ingresso con l'uso di \func{select}, ma non vale
-altrettanto per l'I/O in uscita. Il problema pertanto può sorgere qualora una
-delle chiamate a \func{write} effettuate da \func{FullWrite} si blocchi. Con
-il funzionamento normale questo non accade in quanto il server si limita a
-scrivere quanto riceve in ingresso, ma qualora venga utilizzato un client
-malevolo che esegua solo scritture e non legga mai indietro l'\textsl{eco} del
-server, si potrebbe giungere alla saturazione del buffer di scrittura, ed al
-conseguente blocco del server su di una \func{write}.
+\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}. Il problema è
+che in caso di blocco di una qualunque delle funzioni di I/O, non avendo usato
+processi separati, tutto il server si ferma e non risponde più a nessuna
+richiesta. Abbiamo scongiurato questa evenienza per l'I/O in ingresso con
+l'uso di \func{select}, ma non vale altrettanto per l'I/O in uscita. Il
+problema pertanto può sorgere qualora una delle chiamate a \func{write}
+effettuate da \func{FullWrite} si blocchi. Con il funzionamento normale questo
+non accade in quanto il server si limita a scrivere quanto riceve in ingresso,
+ma qualora venga utilizzato un client malevolo che esegua solo scritture e non
+legga mai indietro l'\textsl{eco} del server, si potrebbe giungere alla
+saturazione del buffer di scrittura, ed al conseguente blocco del server su di
+una \func{write}.
Le possibili soluzioni in questo caso sono quelle di ritornare ad eseguire il
ciclo di risposta alle richieste all'interno di processi separati, utilizzare
queste problematiche con i socket. Abbiamo però visto in
sez.~\ref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo
- delle limitazioni dovute all'uso dei \textit{file descriptor set}.}
+ delle limitazioni dovute all'uso dei \itindex{file~descriptor~set}
+ \textit{file descriptor set}.}
Ancora una volta in sez.~\ref{sec:file_poll} abbiamo trattato la funzione in
maniera generica, parlando di file descriptor, ma come per \func{select}
\item i dati inviati su un socket vengono considerati traffico normale,
pertanto vengono rilevati alla loro ricezione sull'altro capo da una
selezione effettuata con \const{POLLIN} o \const{POLLRDNORM};
-\item i dati \textit{out-of-band} su un socket TCP vengono considerati
+\item i dati urgenti \itindex{out-of-band} \textit{out-of-band} (vedi
+ sez.~\ref{sec:TCP_urgent_data}) su un socket TCP vengono considerati
traffico prioritario e vengono rilevati da una condizione \const{POLLIN},
\const{POLLPRI} o \const{POLLRDBAND}.
\item la chiusura di una connessione (cioè la ricezione di un segmento FIN)
di end-of-file (\texttt{\small 38--47}) si provvederà a chiudere
(\texttt{\small 39}) anche il nostro capo del socket e a marcarlo
(\texttt{\small 40}) nella struttura ad esso associata come inutilizzato.
-Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventiale nuovo
+Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo
valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il
ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro
sul socket.
uscita e notifica in caso si errore (\texttt{\small 49--52}).
Come si può notare la logica del programma è identica a quella vista in
-fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select}; la
-sola differenza significativa è che in questo caso non c'è bisogno di
-rigenerare i file descriptor set in quanto l'uscita è indipendente dai dati in
-ingresso. Si applicano comunque anche a questo server le considerazioni finali
-di sez.~\ref{sec:TCP_serv_select}.
-
-
+fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select};
+la sola differenza significativa è che in questo caso non c'è bisogno di
+rigenerare i \itindex{file~descriptor~set} \textit{file descriptor set} in
+quanto l'uscita è indipendente dai dati in ingresso. Si applicano comunque
+anche a questo server le considerazioni finali di
+sez.~\ref{sec:TCP_serv_select}.
+
+% TODO fare esempio con epoll
+
+
+
+% LocalWords: socket TCP client dell'I multiplexing stream three way handshake
+% LocalWords: header stack kernel SYN ACK URG syncronize sez bind listen fig
+% LocalWords: accept connect active acknowledge l'acknowledge nell'header MSS
+% LocalWords: sequence number l'acknowledgement dell'header options l'header
+% LocalWords: option MMS segment size MAXSEG window advertised Mbit sec nell'
+% LocalWords: timestamp RFC long fat close of l'end l'ACK half shutdown CLOSED
+% LocalWords: netstat SENT ESTABLISHED WAIT IPv Ethernet piggybacking UDP MSL
+% LocalWords: l'overhead Stevens Lifetime router hop limit TTL to live RST SSH
+% LocalWords: routing dell'MSL l'IP multitasking well known port ephemeral BSD
+% LocalWords: ports dall' IANA Assigned Authority like glibc netinet IPPORT AF
+% LocalWords: RESERVED USERRESERVED rsh rlogin pair socketpair Local Address
+% LocalWords: Foreing DNS caching INADDR ANY multihoming loopback ssh fuser ip
+% LocalWords: lsof SOCK sys int sockfd const struct sockaddr serv addr socklen
+% LocalWords: addrlen errno EBADF descriptor EINVAL ENOTSOCK EACCES EADDRINUSE
+% LocalWords: EADDRNOTAVAIL EFAULT ENOTDIR ENOENT ENOMEM ELOOP ENOSR EROFS RPC
+% LocalWords: portmapper htonl tab endianess BROADCAST broadcast any extern fd
+% LocalWords: ADRR INIT DGRAM SEQPACKET servaddr ECONNREFUSED ETIMEDOUT EAGAIN
+% LocalWords: ENETUNREACH EINPROGRESS EALREADY EAFNOSUPPORT EPERM EISCONN proc
+% LocalWords: sysctl filesystem syn retries reset ICMP backlog EOPNOTSUPP RECV
+% LocalWords: connection queue dell'ACK flood spoofing syncookies SOMAXCONN CR
+% LocalWords: RDM EWOULDBLOCK firewall ENOBUFS EINTR EMFILE ECONNABORTED NULL
+% LocalWords: ESOCKTNOSUPPORT EPROTONOSUPPORT ERESTARTSYS connected listening
+% LocalWords: DECnet read write NONBLOCK fcntl getsockname getpeername name ps
+% LocalWords: namelen namlen ENOTCONN exec inetd POSIX daytime FullRead count
+% LocalWords: BUF FullWrite system call INET perror htons inet pton ctime FTP
+% LocalWords: fputs carriage return line feed superdemone daytimed sleep fork
+% LocalWords: daemon cunc logging list conn sock exit snprintf ntop ntohs echo
+% LocalWords: crash superserver L'RFC first ClientEcho stdin stdout fgets main
+% LocalWords: MAXLINE initd echod ServEcho setgid short nogroup nobody setuid
+% LocalWords: demonize PrintErr syslog wrapper log error root RTT EOF ctrl ack
+% LocalWords: while SIGCHLD Signal RESTART sigaction SignalRestart SigHand win
+% LocalWords: flags select recvfrom debug second compat waiting Nsec ENETDOWN
+% LocalWords: EPROTO ENOPROTOOPT EHOSTDOWN ENONET EHOSTUNREACH LINGER tcpdump
+% LocalWords: ECONNRESET advertising PSH SIGTERM strace SIGPIPE gets tcp ARP
+% LocalWords: cache anarres destination unreachable l'I low watermark RCVLOWAT
+% LocalWords: SNDLOWAT third fset maxfd fileno ISSET closed how SHUT RD WR eof
+% LocalWords: RDWR fifo Trip ping fourth CLR sull'I SETSIZE nread break Denial
+% LocalWords: Service poll POLLIN POLLRDNORM POLLPRI POLLRDBAND POLLOUT events
+% LocalWords: POLLHUP POLLERR revents pollfd Di scaling SYNCNT DoS
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff