X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=09759f41ce75011470ac177e0268aa7313c436ca;hp=e26df0b43bdaba560b069e73d198649e600320ea;hb=5077cb02e6a65499d7fddcd01d68e8800c73a6fa;hpb=597364c925b229bd9a8ea1a88d5e1ef885757140 diff --git a/tcpsock.tex b/tcpsock.tex index e26df0b..09759f4 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -1,4 +1,4 @@ -%% tcpsock.tex +S%% tcpsock.tex %% %% Copyright (C) 2000-2016 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free @@ -47,9 +47,9 @@ Il processo che porta a creare una connessione TCP viene chiamato elementare di dati trasmessa dal protocollo TCP al livello successivo; tutti i segmenti hanno un'intestazione che contiene le informazioni che servono allo \textit{stack TCP} (così viene di solito chiamata la parte del kernel - che implementa il protocollo) per realizzare la comunicazione, fra questi - dati 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}) + che realizza il protocollo) per effettuare la comunicazione, fra questi dati + 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 dati che vengono scambiati) che porta alla creazione di una connessione è la @@ -68,7 +68,7 @@ seguente: \textsl{apertura attiva}, dall'inglese \textit{active open}. La chiamata di \func{connect} blocca il processo e causa l'invio da parte del client di un segmento SYN, in sostanza viene inviato al server un pacchetto IP che - contiene solo le instestazioni di IP e TCP (con il numero di sequenza + contiene solo le intestazioni di IP e TCP (con il numero di sequenza iniziale e il flag SYN) e le opzioni di TCP. \item Il server deve dare ricevuto (l'\textit{acknowledge}) del SYN del @@ -148,26 +148,26 @@ connessione. Normalmente vengono usate le seguenti opzioni: 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}, il protocollo TCP implementa il controllo - di flusso attraverso una \textit{advertised window} (la ``\textsl{finestra - annunciata}'', vedi sez.~\ref{sec:tcp_protocol}) 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{in Linux il 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. +\item \textit{window scale option}, il protocollo TCP realizza il controllo di + flusso attraverso una \textit{advertised window} (la ``\textsl{finestra + annunciata}'', vedi sez.~\ref{sec:tcp_protocol}) 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{in Linux il massimo è 32767 per evitare + problemi con alcune realizzazione dello \textit{stack TCP} che usano + l'aritmetica con segno.} 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 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 - garantire la compatibilità con delle vecchie implementazioni del protocollo - la procedura che la attiva prevede come negoziazione che l'altro capo della + 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 - SYN di risposta dell'apertura della connessione. + SYN di risposta dell'apertura della connessione. Con Linux è possibile indicare al kernel di far negoziare il fattore di scala in fase di creazione di una connessione tramite la \textit{sysctl} @@ -186,7 +186,7 @@ connessione. Normalmente vengono usate le seguenti opzioni: \end{itemize} La \textit{MSS option} è generalmente supportata da quasi tutte le -implementazioni del protocollo, le ultime due opzioni (trattate +realizzazioni 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 @@ -331,9 +331,9 @@ connessione che esegue la chiusura attiva entra nello stato \texttt{TIME\_WAIT}, sul cui significato 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 +e uno di risposta) TCP necessiti di ulteriori otto segmenti, se invece si fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il -costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si +costo che occorre pagare per avere l'affidabilità garantita da TCP, se si fosse usato UDP si sarebbe dovuto trasferire la gestione di tutta una serie di dettagli (come la verifica della ricezione dei pacchetti) dal livello del trasporto all'interno dell'applicazione. @@ -346,6 +346,7 @@ per questo esistono applicazioni che usano UDP e lo fanno perché nel caso specifico le sue caratteristiche di velocità e compattezza nello scambio dei dati rispondono meglio alle esigenze che devono essere affrontate. + \subsection{Lo stato \texttt{TIME\_WAIT}} \label{sec:TCP_time_wait} @@ -372,20 +373,21 @@ 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 stimare che un pacchetto IP non possa restare nella rete per più -un certo numero di secondi che costituisce la \textit{Maximum Segment Lifetime}. - -Ogni implementazione del TCP deve scegliere un valore per la MSL -(l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti, -Linux usa 30 secondi), questo comporta una durata dello stato -\texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4 +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}. + +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, +mentre Linux usa 30 secondi, questo comporta una durata dello stato +\texttt{TIME\_WAIT} che a seconda delle realizzazioni può variare fra 1 a 4 minuti. Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due motivi principali: -\begin{enumerate} -\item implementare in maniera affidabile la terminazione della connessione +\begin{enumerate*} +\item effettuare in maniera affidabile la terminazione della connessione in entrambe le direzioni. \item consentire l'eliminazione dei segmenti duplicati dalla rete. -\end{enumerate} +\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 @@ -410,7 +412,7 @@ l'eventuale ritrasmissione, in caso esso venga perduto. Il secondo motivo è più complesso da capire, e necessita di una spiegazione degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella -rete o restare intrappolati, per poi riemergere in un secondo tempo. +rete o restare intrappolati, per poi riemergere in un secondo tempo. Il caso più comune in cui questo avviene è quello di anomalie nell'instradamento; può accadere cioè che un router smetta di funzionare o che @@ -467,15 +469,15 @@ Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i sez.~\ref{sec:sock_sa_ipv4} e sez.~\ref{sec:sock_sa_ipv6} pure delle strutture degli indirizzi del socket. -Quando un client contatta un server deve poter identificare con quale dei vari -possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo -di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che -identificano una serie di servizi noti (ad esempio la porta 22 identifica il -servizio SSH) effettuati da appositi server che rispondono alle connessioni -verso tali porte. +Quando un client contatta una macchina server deve poter identificare con +quale dei vari possibili programmi server attivi intende parlare. Sia TCP che +UDP definiscono un gruppo di \textsl{porte conosciute} (le cosiddette +\textit{well-known port}) che identificano una serie di servizi noti (ad +esempio la porta 22 identifica il servizio SSH) effettuati da appositi +programmi server che rispondono alle connessioni verso tali porte. -D'altra parte un client non ha necessità di usare un numero di porta -specifico, per cui in genere vengono usate le cosiddette \textsl{porte +D'altra parte un client non ha necessità di usare dalla sua parte un numero di +porta specifico, per cui in genere vengono usate le cosiddette \textsl{porte effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato nessun servizio noto e che vengono assegnate automaticamente dal kernel alla creazione della connessione. Queste sono dette effimere in quanto vengono @@ -486,7 +488,7 @@ La lista delle porte conosciute è definita dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene 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 +Internet (una versione aggiornata si può trovare all'indirizzo \url{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 @@ -501,9 +503,9 @@ servizio. I numeri sono divisi in tre intervalli: \item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non sono controllate dalla IANA, che però registra ed elenca chi usa queste porte come servizio agli utenti. Come per le precedenti si assegna una porta - ad un servizio sia per TCP che UDP anche se poi il servizio è implementato - solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063 - anche se il protocollo è implementato solo tramite TCP. + ad un servizio sia per TCP che UDP anche se poi il servizio è effettuato + solo su TCP. Ad esempio \textit{X Window} usa le porte TCP e UDP dal 6000 al + 6063 anche se il protocollo viene usato solo con TCP. \item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a 65535. La IANA non dice nulla riguardo a queste porte che pertanto @@ -521,14 +523,14 @@ fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux. \label{fig:TCP_port_alloc} \end{figure} -I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che +I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate}, che corrispondono alle porte con numero minore di 1024 e coincidono quindi con le -\textsl{porte note}). La loro caratteristica è che possono essere assegnate a +\textsl{porte note}. La loro caratteristica è che possono essere assegnate a un socket solo da un processo con i privilegi di amministratore, per far sì che solo l'amministratore possa allocare queste porte per far partire i relativi servizi. -Le \textsl{glibc} definiscono in \headfile{netinet/in.h} +Le \textsl{glibc} definiscono in \headfile{netinet/in.h} le costanti \constd{IPPORT\_RESERVED} e \constd{IPPORT\_USERRESERVED}, in cui la prima (che vale 1024) indica il limite superiore delle porte riservate, e la seconda (che vale 5000) il limite inferiore delle porte a disposizione degli utenti. @@ -545,19 +547,20 @@ solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo disuso. -Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da - non confondere con la coppia di socket della omonima funzione - \func{socketpair} che fanno riferimento ad una coppia di socket sulla stessa - macchina, non ai capi di una connessione TCP.} la combinazione dei quattro -numeri che definiscono i due capi della connessione e cioè l'indirizzo IP -locale e la porta TCP locale, e l'indirizzo IP remoto e la porta TCP remota. -Questa combinazione, che scriveremo usando una notazione del tipo -(\texttt{195.110.112.152:22}, \texttt{192.84.146.100:20100}), identifica -univocamente una connessione su internet. Questo concetto viene di solito -esteso anche a UDP, benché in questo caso non abbia senso parlare di -connessione. L'utilizzo del programma \cmd{netstat} permette di visualizzare -queste informazioni nei campi \textit{Local Address} e \textit{Foreing - Address}. +Data una connessione TCP, ma la cosa vale anche per altri protocolli del +livello di trasporto come UDP, si suole chiamare \itindex{socket~pair} +\textit{socket pair}\footnote{da non confondere con la coppia di socket della + omonima funzione \func{socketpair} di sez.~\ref{sec:ipc_socketpair} che + fanno riferimento ad una coppia di socket sulla stessa macchina, non ai capi + di una connessione TCP.} la combinazione dei quattro numeri che definiscono +i due capi della connessione e cioè l'indirizzo IP locale e la porta TCP +locale, e l'indirizzo IP remoto e la porta TCP remota. Questa combinazione, +che scriveremo usando una notazione del tipo (\texttt{195.110.112.152:22}, +\texttt{192.84.146.100:20100}), identifica univocamente una connessione su +Internet. Questo concetto viene di solito esteso anche a UDP, benché in +questo caso non abbia senso parlare di connessione. L'utilizzo del programma +\cmd{netstat} permette di visualizzare queste informazioni nei campi +\textit{Local Address} e \textit{Foreing Address}. \subsection{Le porte ed il modello client/server} @@ -571,13 +574,13 @@ gestire connessioni multiple. Se eseguiamo un \cmd{netstat} su una macchina di prova (il cui indirizzo sia \texttt{195.110.112.152}) potremo avere un risultato del tipo: -\begin{verbatim} +\begin{Terminal} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN -\end{verbatim} +\end{Terminal} essendo presenti e attivi un server SSH, un server di posta e un DNS per il caching locale. @@ -599,31 +602,31 @@ Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può chiedere che senso abbia l'utilizzo dell'indirizzo generico per specificare l'indirizzo locale; ma a parte il caso di macchine che hanno più di un indirizzo IP (il cosiddetto \textit{multihoming}) esiste sempre anche -l'indirizzo di loopback, per cui con l'uso dell'indirizzo generico si possono -accettare connessioni indirizzate verso uno qualunque degli indirizzi IP -presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto +l'indirizzo di \textit{loopback}, per cui con l'uso dell'indirizzo generico si +possono accettare connessioni indirizzate verso uno qualunque degli indirizzi +IP presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto sulla porta 53, è possibile anche restringere l'accesso ad uno specifico indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino -sull'interfaccia di loopback. +sull'interfaccia di \textit{loopback}. Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su quest'ultima un client \cmd{ssh} per creare una connessione, e il kernel gli assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà -espressa dalla socket pair (\texttt{192.84.146.100:21100}, +espressa dalla \textit{socket pair} (\texttt{192.84.146.100:21100}, \texttt{195.110.112.152:22}). Alla ricezione della richiesta dal client il server creerà un processo figlio per gestire la connessione, se a questo punto eseguiamo nuovamente il programma \cmd{netstat} otteniamo come risultato: -\begin{verbatim} +\begin{Terminal} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED -\end{verbatim} +\end{Terminal} Come si può notare il server è ancora in ascolto sulla porta 22, però adesso c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso @@ -634,7 +637,7 @@ sul socket originale. Se a questo punto lanciamo un'altra volta il client \cmd{ssh} per una seconda connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del genere: -\begin{verbatim} +\begin{Terminal} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN @@ -642,19 +645,19 @@ tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED tcp 0 0 195.110.112.152:22 192.84.146.100:21101 ESTABLISHED -\end{verbatim} +\end{Terminal} cioè il client effettuerà la connessione usando un'altra porta effimera: con questa sarà aperta la connessione, ed il server creerà un altro processo figlio per gestirla. Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server concorrente, non può suddividere i pacchetti solo sulla base della porta di -destinazione, ma deve usare tutta l'informazione contenuta nella socket pair, -compresa la porta dell'indirizzo remoto. E se andassimo a vedere quali sono i -processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}, o - usando l'opzione \texttt{-p}.} a cui fanno riferimento i vari socket -vedremmo che i pacchetti che arrivano dalla porta remota 21100 vanno al primo -figlio e quelli che arrivano alla porta 21101 al secondo. +destinazione, ma deve usare tutta l'informazione contenuta nella +\textit{socket pair}, compresa la porta dell'indirizzo remoto. E se andassimo +a vedere quali sono i processi (ad esempio con il comando \cmd{fuser}, o con +\cmd{lsof}, o usando l'opzione \texttt{-p}) a cui fanno riferimento i vari +socket vedremmo che i pacchetti che arrivano dalla porta remota 21100 vanno al +primo figlio e quelli che arrivano alla porta 21101 al secondo. \section{Le funzioni di base per la gestione dei socket} @@ -670,34 +673,41 @@ precedente in sez.~\ref{sec:sock_creation}. \label{sec:TCP_func_bind} La funzione \funcd{bind} assegna un indirizzo locale ad un -socket.\footnote{nel nostro caso la utilizzeremo per socket TCP, ma la +socket,\footnote{nel nostro caso la utilizzeremo per socket TCP, ma la funzione è generica e deve essere usata per qualunque tipo di socket - \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata -cioè per specificare la prima parte dalla socket pair. Viene usata sul lato -server per specificare la porta (e gli eventuali indirizzi locali) su cui poi -ci si porrà in ascolto. Il prototipo della funzione è il seguente: -\begin{prototype}{sys/socket.h} -{int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t addrlen)} - - Assegna un indirizzo ad un socket. - - \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore; - in caso di errore la variabile \var{errno} viene impostata secondo i - seguenti codici di errore: + \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} ed è +usata cioè per specificare la prima parte dalla \textit{socket pair}. Viene +usata sul lato server per specificare la porta (e gli eventuali indirizzi +locali) su cui poi ci si porrà in ascolto. Il prototipo della funzione è il +seguente: + + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t + addrlen)} +\fdesc{Assegna un indirizzo ad un socket.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \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{EBADF}] il file descriptor non è valido. \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato. \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket. - \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza - sufficienti privilegi. + \end{errlist} + 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. - \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo. \end{errlist} - ed anche \errval{EFAULT} e per i socket di tipo \const{AF\_UNIX}, - \errval{ENOTDIR}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ELOOP}, - \errval{ENOSR} e \errval{EROFS}.} -\end{prototype} + ed \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, + \errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.} +\end{funcproto} Il primo argomento è un file descriptor ottenuto da una precedente chiamata a \func{socket}, mentre il secondo e terzo argomento sono rispettivamente @@ -718,17 +728,19 @@ cui risponde (l'elenco di queste porte, e dei relativi servizi, è in \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 +purché questo appartenga ad una interfaccia della macchina. Per un client TCP questo diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati sul socket, mentre per un server TCP questo restringerà l'accesso al socket solo alle connessioni che arrivano verso tale indirizzo. Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla -base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle -regole di instradamento usate per raggiungere il server). Se un server non -specifica il suo indirizzo locale il kernel userà come indirizzo di origine -l'indirizzo di destinazione specificato dal SYN del client. +base dell'interfaccia usata per trasmettere i pacchetti, che dipenderà dalle +regole di instradamento usate per raggiungere il server (è comunque possibile +impostarlo in maniera specifica con i comandi di gestione avanzata del +routing, vedi sez.~7.3.4 di \cite{AGL}). Se un server non specifica il suo +indirizzo locale il kernel userà come indirizzo di origine l'indirizzo di +destinazione specificato dal SYN del client. Per specificare un indirizzo generico, con IPv4 si usa il valore \const{INADDR\_ANY}, il cui valore, come accennato in @@ -790,36 +802,40 @@ connessione con un server TCP,\footnote{di nuovo la funzione è generica e \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: -\begin{prototype}{sys/socket.h} - {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t + + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t addrlen)} - - Stabilisce una connessione fra due socket. - - \bodydesc{La funzione restituisce zero in caso di successo e -1 per un - errore, nel qual caso \var{errno} assumerà i valori: +\fdesc{Stabilisce una connessione fra due socket.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \begin{errlist} + \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una + connessione ad un indirizzo \textit{broadcast} senza che il socket fosse + stato abilitato per il \textit{broadcast}. + \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi + corretta nel relativo campo. + \item[\errcode{EAGAIN}] non ci sono più porte locali libere. + \item[\errcode{EALREADY}] il socket è non bloccante (vedi + sez.~\ref{sec:file_noblocking}) e un tentativo precedente di connessione + non si è ancora concluso. \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo remoto. - \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di - connessione. - \item[\errcode{ENETUNREACH}] la rete non è raggiungibile. \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa immediatamente. - \item[\errcode{EALREADY}] il socket è non bloccante (vedi - sez.~\ref{sec:file_noblocking}) e un tentativo precedente di connessione - non si è ancora concluso. - \item[\errcode{EAGAIN}] non ci sono più porte locali libere. - \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 \textit{broadcast} senza che il socket fosse - stato abilitato per il \textit{broadcast}. + \item[\errcode{ENETUNREACH}] la rete non è raggiungibile. + \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di + connessione. \end{errlist} - altri errori possibili sono: \errval{EFAULT}, \errval{EBADF}, - \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.} -\end{prototype} + ed inoltre \errval{EADDRINUSE}, \errval{EBADF}, \errval{EFAULT}, + \errval{EINTR}, \errval{EISCONN} e \errval{ENOTSOCK} e nel loro significato + generico.} +\end{funcproto} Il primo argomento è un file descriptor ottenuto da una precedente chiamata a \func{socket}, mentre il secondo e terzo argomento sono rispettivamente @@ -827,9 +843,9 @@ l'indirizzo e la dimensione della struttura che contiene l'indirizzo del socket, già descritta in sez.~\ref{sec:sock_sockaddr}. 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 sez.~\ref{sec:TCP_daytime_client}, usando le funzioni illustrate -in sez.~\ref{sec:sock_addr_func}. +numero di porta del server a cui ci si vuole connettere usando le funzioni +illustrate in sez.~\ref{sec:sock_addr_func} come mostrato nell'esempio che +vedremo in sez.~\ref{sec:TCP_daytime_client}. Nel caso di socket TCP la funzione \func{connect} avvia il \textit{three way handshake}, e ritorna solo quando la connessione è stabilita o si è @@ -844,13 +860,13 @@ seguenti: 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 - \sysctlfile{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. + può essere fatto a livello globale con una opportuna \func{sysctl} (o più + semplicemente scrivendo il valore voluto in + \sysctlfile{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 @@ -875,16 +891,16 @@ seguenti: \end{enumerate} Se si fa riferimento al diagramma degli stati del TCP riportato in -fig.~\ref{fig:TCP_state_diag} la funzione \func{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 -socket non è più utilizzabile e deve essere chiuso. +fig.~\ref{fig:TCP_state_diag} la funzione \func{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 dell'ACK, +nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il socket +non è più utilizzabile e deve essere chiuso. Si noti infine che con la funzione \func{connect} si è specificato solo -indirizzo e porta del server, quindi solo una metà della socket pair; essendo -questa funzione usata nei client l'altra metà contenente indirizzo e porta -locale viene lasciata all'assegnazione automatica del kernel, e non è +indirizzo e porta del server, quindi solo una metà della \textit{socket pair}; +essendo questa funzione usata nei client l'altra metà contenente indirizzo e +porta locale viene lasciata all'assegnazione automatica del kernel, e non è necessario effettuare una \func{bind}. @@ -900,58 +916,65 @@ il socket dallo stato \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in un server dopo le chiamate a \func{socket} e \func{bind} e prima della chiamata ad \func{accept}. Il prototipo della funzione, come definito dalla pagina di manuale, è: -\begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)} - Pone un socket in attesa di una connessione. - - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore. I codici di errore restituiti in \var{errno} sono i seguenti: + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int listen(int sockfd, int backlog)} +\fdesc{Pone un socket in attesa di una connessione.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \begin{errlist} + \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo. \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor valido. \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket. \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa operazione. - \end{errlist}} -\end{prototype} + \end{errlist} +} +\end{funcproto} La funzione pone il socket specificato da \param{sockfd} in modalità passiva e predispone una coda per le connessioni in arrivo di lunghezza pari a \param{backlog}. La funzione si può applicare solo a socket di tipo -\const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}. - -L'argomento \param{backlog} indica il numero massimo di connessioni pendenti -accettate; se esso viene ecceduto il client al momento della richiesta della -connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il -protocollo, come accade nel caso del TCP, supporta la ritrasmissione, la -richiesta sarà ignorata in modo che la connessione possa venire ritentata. +\const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}. L'argomento \param{backlog} +indica il numero massimo di connessioni pendenti accettate; se esso viene +ecceduto il client al momento della richiesta della connessione riceverà un +errore di tipo \errcode{ECONNREFUSED}, o se il protocollo, come accade nel +caso del TCP, supporta la ritrasmissione, la richiesta sarà ignorata in modo +che la connessione possa venire ritentata. Per capire meglio il significato di tutto ciò occorre approfondire la modalità con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto 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 \textit{three way handshake} non si è ancora concluso. - Questi socket sono tutti nello stato \texttt{SYN\_RECV}. + queue}) che contiene una voce per ciascun socket per il quale è arrivato + un SYN ma il \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. + che contiene una voce 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}. \end{enumerate} Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}: -quando arriva un SYN da un client il server crea una nuova voce nella coda -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 \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 è vuota, il processo viene -posto in attesa e risvegliato all'arrivo della prima connessione completa. +quando arriva un segmento SYN da un client il kernel crea una voce nella coda +delle connessioni incomplete e risponde con il segmento SYN$+$ACK. La voce +resterà nella coda delle connessioni incomplete fino al ricevimento del +segmento ACK dal client o fino ad un timeout. + +Nel caso di completamento del \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}) gli viene passata +la prima voce nella coda delle connessioni complete, oppure, se la coda è +vuota, il processo viene posto in attesa in stato di \textit{sleep} e +risvegliato all'arrivo della prima connessione completa. \begin{figure}[!htb] - \centering \includegraphics[width=11cm]{img/tcp_listen_backlog} + \centering \includegraphics[width=12cm]{img/tcp_listen_backlog} \caption{Schema di funzionamento delle code delle connessioni complete ed incomplete.} \label{fig:TCP_listen_backlog} @@ -961,118 +984,135 @@ Storicamente il valore dell'argomento \param{backlog} era corrispondente al massimo valore della somma del numero di voci possibili per ciascuna delle due code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di 1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari -kernel, compreso Linux 2.0, che mostrano le differenze fra diverse -implementazioni. +kernel, compreso anche il vecchio Linux 2.0, che mostrano le differenze fra +diverse realizzazioni. In Linux il significato di questo valore è cambiato a partire dal kernel 2.2 -per prevenire l'attacco chiamato \itindex{SYN~flood} \textit{SYN - flood}. Questo si basa sull'emissione da parte dell'attaccante di un grande -numero di pacchetti SYN indirizzati verso una porta, forgiati con indirizzo IP -fasullo\footnote{con la tecnica che viene detta \textit{ip spoofing}.} così -che i SYN$+$ACK vanno perduti e la coda delle connessioni incomplete viene -saturata, impedendo di fatto ulteriori connessioni. - -Per ovviare a questo il significato del \param{backlog} è stato cambiato a -indicare la lunghezza della coda delle connessioni complete. La lunghezza -della coda delle connessioni incomplete può essere ancora controllata usando -la funzione \func{sysctl} con il parametro -\constd{NET\_TCP\_MAX\_SYN\_BACKLOG} o scrivendola direttamente in -\sysctlfile{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 \sysctlfile{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 è -molto cambiata per via della presenza di server web che devono gestire un gran -numero di connessioni per cui un tale valore non è più adeguato. Non esiste -comunque una risposta univoca per la scelta del valore, per questo non -conviene specificarlo con una costante (il cui cambiamento richiederebbe la -ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi -sez.~\ref{sec:proc_environ}). +per prevenire il \textit{denial of service} chiamato \itindex{SYN~flood} +\textit{SYN flood}. Questo attacco si basa sull'emissione da parte +dell'attaccante di un grande numero di segmenti SYN indirizzati verso una +porta, forgiati con indirizzo IP fasullo (con la tecnica che viene detta +\textit{ip spoofing}); in questo modo i segmenti SYN$+$ACK di risposta vanno +perduti e la coda delle connessioni incomplete viene saturata, impedendo di +fatto ulteriori connessioni. + +Per ovviare a questo problema il significato del \param{backlog} è stato +cambiato e adesso indica la lunghezza della coda delle connessioni +complete. La lunghezza della coda delle connessioni incomplete può essere +ancora controllata ma occorre usare esplicitamente la funzione \func{sysctl} +con il parametro \constd{NET\_TCP\_MAX\_SYN\_BACKLOG} o scrivere il valore +direttamente sul file \sysctlfile{net/ipv4/tcp\_max\_syn\_backlog}. + +Quando si attiva la protezione dei \textit{syncookies} però (con l'opzione da +compilare nel kernel e da attivare usando \func{sysctl} o scrivendo nel file +\sysctlfile{net/ipv4/tcp\_syncookies}, vedi sez.~\ref{sec:sock_ipv4_sysctl}) +questo valore viene ignorato e non esiste più un valore massimo. In ogni caso +in Linux il valore di \param{backlog} viene sempre troncato ad un massimo di +\const{SOMAXCONN} se è superiore a detta costante (che di default vale 128); +per i kernel precedenti il 2.4.25 questo valore era fisso e non modificabile, +nelle versioni successive può essere controllato con un parametro di +\func{sysctl}, o scrivendo nel file \sysctlfile{net/core/somaxconn} +(vedi sez.~\ref{sec:sock_ioctl_IP}). + +La scelta storica per il valore assegnato a questo argomento era di 5, e +alcuni vecchi kernel non supportavano neanche valori superiori, ma la +situazione corrente è molto cambiata per via della presenza di server web che +devono gestire un gran numero di connessioni per cui un tale valore non è più +adeguato. Non esiste comunque una risposta univoca per la scelta del valore, +per questo non conviene specificarlo con una costante (il cui cambiamento +richiederebbe la ricompilazione del server) ma usare piuttosto una variabile +di ambiente (vedi sez.~\ref{sec:proc_environ}). Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi -da casi reali su web server, ed in particolare evidenzia come non sia più vero -che il compito principale della coda sia quello di gestire il caso in cui il -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}. - -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 -condizione in cui le code sono piene è ovviamente transitoria, per cui se il -client ritrasmette il SYN è probabile che passato un po' di tempo possa -trovare nella coda lo spazio per una nuova connessione. Se invece si -rispondesse con un RST, per indicare l'impossibilità di effettuare la -connessione, la chiamata a \func{connect} nel client ritornerebbe con una -condizione di errore, costringendo a inserire nell'applicazione la gestione -dei tentativi di riconnessione, che invece può essere effettuata in maniera -trasparente dal protocollo TCP. +da casistiche reali trovate su dei server web, ed in particolare evidenzia +come non sia più vero che il compito principale della coda sia quello di +gestire il caso in cui il 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}. + +Infine va messo in evidenza che, nel caso di socket TCP, quando un segmento +SYN arriva con tutte le code piene, il pacchetto verrà semplicemente +ignorato. Questo avviene perché la condizione in cui le code sono piene è +ovviamente transitoria, per cui se il client ritrasmette in seguito un +segmento SYN, come previsto dal protocollo, è probabile che essendo passato un +po' di tempo esso possa trovare nella coda lo spazio per una nuova +connessione. + +Se al contrario si rispondesse immediatamente con un segmento RST, per +indicare che è impossibile effettuare la connessione, la chiamata a +\func{connect} eseguita dal client fallirebbe ritornando una condizione di +errore. In questo modo si sarebbe costretti ad inserire nell'applicazione la +gestione dei tentativi di riconnessione, che invece grazie a questa modalità +di funzionamento viene effettuata in maniera trasparente dal protocollo +TCP. \subsection{La funzione \func{accept}} \label{sec:TCP_func_accept} -La funzione \funcd{accept} è chiamata da un server per gestire la connessione -una volta che sia stato completato il \textit{three way - handshake},\footnote{la funzione è comunque generica ed è utilizzabile su - socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} e - \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su -cui si potrà operare per effettuare la comunicazione. Se non ci sono +La funzione \funcd{accept} è chiamata da un server per gestire la connessione, +nel caso di TCP una volta che sia stato completato il \textit{three way + handshake};\footnote{come le precedenti, la funzione è generica ed è + utilizzabile su socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} + e \const{SOCK\_RDM}, ma qui la tratteremo solo per gli aspetti riguardanti + le connessioni con TCP.} la funzione restituisce un nuovo socket descriptor +su cui si potrà operare per effettuare la comunicazione. Se non ci sono connessioni completate il processo viene messo in attesa. Il prototipo della funzione è il seguente: -\begin{prototype}{sys/socket.h} -{int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)} - - Accetta una connessione sul socket specificato. - - \bodydesc{La funzione restituisce un numero di socket descriptor positivo in - caso di successo e -1 in caso di errore, nel qual caso \var{errno} viene - impostata ai seguenti valori: +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)} +\fdesc{Accetta una connessione sul socket specificato.} +} + +{La funzione ritorna un numero di socket descriptor positivo in caso di + successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei + valori: \begin{errlist} + \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato + come non bloccante (vedi sez.~\ref{sec:file_noblocking}), e non ci sono + connessioni in attesa di essere accettate. In generale possono essere + restituiti entrambi i valori, per cui se si ha a cuore la portabilità + occorre controllare entrambi. \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor valido. + \item[\errcode{ECONNABORTED}] la connessione è stata abortita. + \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale. + \item[\errcode{EINVAL}] il socket non è in ascolto o \param{addrlen} non ha + un valore valido. + \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che + l'allocazione della memoria è limitata dai limiti sui buffer dei socket, + non dalla memoria di sistema. \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket. \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa operazione. - \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato - come non bloccante (vedi sez.~\ref{sec:file_noblocking}), e non ci sono - connessioni in attesa di essere accettate. \item[\errcode{EPERM}] le regole del firewall non consentono la connessione. - \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che - l'allocazione della memoria è limitata dai limiti sui buffer dei socket, - non dalla memoria di sistema. - \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale. \end{errlist} - Inoltre possono essere restituiti gli errori di rete relativi al nuovo - socket, diversi a secondo del protocollo, come: \errval{EMFILE}, - \errval{EINVAL}, \errval{ENOSR}, \errval{ENOBUFS}, \errval{EFAULT}, - \errval{EPERM}, \errval{ECONNABORTED}, \errval{ESOCKTNOSUPPORT}, - \errval{EPROTONOSUPPORT}, \errval{ETIMEDOUT}, \errval{ERESTARTSYS}.} -\end{prototype} + ed inoltre nel loro significato generico: \errval{EFAULT}, \errval{EMFILE}, + \errval{ENFILE}; infine a seconda del protocollo e del kernel possono essere + restituiti errori di rete relativi al nuovo socket come: \errval{ENOSR}, + \errval{ESOCKTNOSUPPORT}, \errval{EPROTONOSUPPORT}, \errval{ETIMEDOUT}, + \errval{ERESTARTSYS}.} +\end{funcproto} La funzione estrae la prima connessione relativa al socket \param{sockfd} in attesa sulla coda delle connessioni complete, che associa ad nuovo socket con le stesse caratteristiche di \param{sockfd}. Il socket originale non viene toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene -posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella -variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza -del client che si è connesso. - -I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è -passato per indirizzo per avere indietro il valore) sono usati per ottenere -l'indirizzo del client da cui proviene la connessione. Prima della chiamata -\param{addrlen} deve essere inizializzato alle dimensioni della struttura il -cui indirizzo è passato come argomento in \param{addr}; al ritorno della -funzione \param{addrlen} conterrà il numero di byte scritti dentro -\param{addr}. Se questa informazione non interessa basterà inizializzare a -\val{NULL} detti puntatori. +posto nello stato \texttt{ESTABLISHED}. + +I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è un +\textit{valure-result argument} passato con un puntatore per riavere indietro +il valore) sono usati rispettivamente per ottenere l'indirizzo del client da +cui proviene la connessione e la lunghezza dello stesso; la dimensione dipende +da quale famiglia di indirizzi si sta utilizzando. Prima della +chiamata \param{addrlen} deve essere inizializzato alle dimensioni della +struttura degli indirizzi cui punta \param{addr} (un numero positivo); al +ritorno della funzione \param{addrlen} conterrà il numero di byte scritti +dentro \param{addr}. Se questa informazione non interessa basterà +inizializzare a \val{NULL} detti puntatori. Se la funzione ha successo restituisce il descrittore di un nuovo socket creato dal kernel (detto \textit{connected socket}) a cui viene associata la @@ -1094,20 +1134,66 @@ esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha questo comportamento.} la funzione opera solo l'estrazione dalla coda delle connessioni, la conferma della connessione viene eseguita implicitamente dalla prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della -connessione viene eseguito con la funzione \func{close}. - -È da chiarire che Linux presenta un comportamento diverso nella gestione degli -errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione -\func{accept} passa gli errori di rete pendenti sul nuovo socket come codici -di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed -eventualmente ripetere la chiamata alla funzione come per l'errore di -\errcode{EAGAIN} (torneremo su questo in sez.~\ref{sec:TCP_echo_critical}). +connessione viene eseguito con la funzione \func{close}. + +Si tenga presente che con Linux, seguendo POSIX.1, è sufficiente includere +\texttt{sys/socket.h}, ma alcune implementazioni di altri sistemi possono +richiedere l'inclusione di \texttt{sys/types.h}, per cui dovendo curare la +portabilità può essere il caso di includere anche questo file. Inoltre Linux +presenta un comportamento diverso nella gestione degli errori rispetto ad +altre realizzazioni dei socket BSD, infatti la funzione \func{accept} passa +gli errori di rete pendenti sul nuovo socket come codici di errore per +\func{accept}, per cui l'applicazione deve tenerne conto ed eventualmente +ripetere la chiamata alla funzione come per l'errore di \errcode{EAGAIN} +(torneremo su questo in sez.~\ref{sec:TCP_echo_critical}). + Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale tutti quelli che si possono impostare con \func{fcntl}, vedi sez.~\ref{sec:file_fcntl_ioctl}.} che devono essere rispecificati ogni volta. Tutto questo deve essere tenuto in conto se si devono scrivere -programmi portabili. +programmi portabili. Per poter effettuare questa impostazione in maniera +atomica, senza dover ricorrere ad ulteriori chiamate a \func{fcntl} su Linux è +disponibile anche la funzione \funcd{accept4}, il cui prototipo è:\footnote{la + funzione è utilizzabile solo se si è definito la macro \macro{\_GNU\_SOURCE} + ed ovviamente non è portabile.} + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int accept4(int sockfd, struct sockaddr *addr, socklen\_t *addrlen, int + flags)} +\fdesc{Accetta una connessione sul socket specificato.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà gli stessi valori di \func{accept}.} +\end{funcproto} + +La funzione aggiunge un quarto argomento \param{flags} usato come maschera +binaria, e se questo è nullo il suo comportamento è identico a quello di +\func{accept}. Con \param{flags} si possono impostare contestualmente +all'esecuzione sul file descriptor restituito i due flag di +\const{O\_NONBLOCK} e \const{O\_CLOEXEC}, fornendo un valore che sia un OR +aritmetico delle costanti in tab.\ref{tab:accept4_flags_arg}. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Costante} & \textbf{Significato} \\ + \hline + \hline + \constd{SOCK\_NONBLOCK} & imposta sul file descriptor restituito il flag + di \const{O\_NONBLOCK}\\ + \constd{SOCK\_NOXEC} & imposta sul file descriptor restituito il flag + di \const{O\_CLOEXEC}\\ + \hline + \end{tabular} + \caption{Costanti per i possibili valori dell'argomento \param{flags} di + \func{accept4}.} + \label{tab:accept4_flags_arg} +\end{table} Il meccanismo di funzionamento di \func{accept} è essenziale per capire il funzionamento di un server: in generale infatti c'è sempre un solo socket in @@ -1128,66 +1214,71 @@ dati. Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono alcune funzioni ausiliarie che possono essere usate per recuperare alcune informazioni relative ai socket ed alle connessioni ad essi associate. Le due -funzioni più elementari sono queste, che vengono usate per ottenere i dati -relativi alla socket pair associata ad un certo socket. - -La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale -associato ad un socket; il suo prototipo è: -\begin{prototype}{sys/socket.h} - {int getsockname(int sockfd, struct sockaddr *name, socklen\_t *namelen)} - Legge l'indirizzo locale di un socket. - -\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore. I codici di errore restituiti in \var{errno} sono i seguenti: +più elementari sono le seguenti, usate per ottenere i dati relativi alla +\textit{socket pair} associata ad un certo socket. La prima è +\funcd{getsockname} e serve ad ottenere l'indirizzo locale associato ad un +socket; il suo prototipo è: + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int getsockname(int sockfd, struct sockaddr *name, socklen\_t *namelen)} +\fdesc{Legge l'indirizzo locale di un socket.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor valido. - \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket. \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per + \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket. eseguire l'operazione. - \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido. - \end{errlist}} -\end{prototype} + \end{errlist} + ed \errval{EFAULT} nel suo significato generico.} +\end{funcproto} La funzione restituisce la struttura degli indirizzi del socket \param{sockfd} nella struttura indicata dal puntatore \param{name} la cui lunghezza è -specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato -come indirizzo per avere indietro anche il numero di byte effettivamente -scritti nella struttura puntata da \param{name}. Si tenga presente che se si è -utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà -troncato. +specificata tramite l'argomento \param{namlen}. Quest'ultimo è un +\textit{value result argument} e pertanto viene passato come indirizzo per +avere indietro anche il numero di byte effettivamente scritti nella struttura +puntata da \param{name}. Si tenga presente che se si è utilizzato un buffer +troppo piccolo per \param{name} l'indirizzo risulterà troncato. La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un socket; ad esempio può essere usata da un client (che usualmente non chiama -\func{bind}) per ottenere numero IP e porta locale associati al socket +\func{bind}) per ottenere l'indirizzo IP e la porta locale associati al socket restituito da una \func{connect}, o da un server che ha chiamato \func{bind} -su un socket usando 0 come porta locale per ottenere il numero di porta +su un socket usando $0$ come porta locale per ottenere il numero di porta effimera assegnato dal kernel. Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se chiamata dopo il completamento di una connessione sul socket restituito da \func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a -quella connessione. - -Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la -funzione \funcd{getpeername}, il cui prototipo è: -\begin{prototype}{sys/socket.h} - {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)} - Legge l'indirizzo remoto di un socket. - - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore. I codici di errore restituiti in \var{errno} sono i seguenti: +quella connessione. Invece tutte le volte che si vuole avere l'indirizzo +remoto di un socket si usa la funzione \funcd{getpeername}, il cui prototipo +è: + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int getpeername(int sockfd, struct sockaddr * name, socklen\_t * + namelen)} +\fdesc{Legge l'indirizzo remoto di un socket.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor valido. - \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket. - \item[\errcode{ENOTCONN}] il socket non è connesso. \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per eseguire l'operazione. - \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello - spazio di indirizzi del processo. - \end{errlist}} -\end{prototype} + \item[\errcode{ENOTCONN}] il socket non è connesso. + \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket. + \end{errlist} + ed \errval{EFAULT} nel suo significato generico.} +\end{funcproto} + La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma restituisce l'indirizzo remoto del socket, cioè quello associato all'altro @@ -1201,10 +1292,10 @@ Il fatto è che in generale quest'ultimo caso non è sempre possibile. In particolare questo avviene quando il server, invece di gestire la connessione direttamente in un processo figlio, come vedremo nell'esempio di server concorrente di sez.~\ref{sec:TCP_daytime_cunc_server}, lancia per ciascuna -connessione un altro programma, usando \func{exec}.\footnote{questa ad esempio - è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può - gestire tutta una serie di servizi diversi, eseguendo su ogni connessione - ricevuta sulle porte tenute sotto controllo, il relativo server.} +connessione un altro programma, usando \func{exec}. Questa ad esempio è la +modalità con cui opera il \textsl{super-server} \cmd{xinetd}, che può gestire +tutta una serie di servizi diversi, eseguendo su ogni connessione ricevuta +sulle porte tenute sotto controllo, il relativo server. In questo caso benché il processo figlio abbia una immagine della memoria che è copia di quella del processo padre (e contiene quindi anche la struttura @@ -1212,15 +1303,15 @@ ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in memoria l'immagine del programma eseguito, che a questo punto perde ogni riferimento ai valori tornati da \func{accept}. Il socket descriptor però resta aperto, e se si è seguita una opportuna convenzione per rendere noto al -programma eseguito qual è il socket connesso, \footnote{ad esempio il solito - \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano - al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername} -per determinare l'indirizzo remoto del client. +programma eseguito qual è il socket connesso (ad esempio il solito +\cmd{xinetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano al +socket connesso) quest'ultimo potrà usare la funzione \func{getpeername} per +determinare l'indirizzo remoto del client. Infine è da chiarire (si legga la pagina di manuale) che, come per \func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un -\ctyp{int *} come prima dello standard perché tutte le implementazioni dei +\ctyp{int *} come prima dello standard, perché tutte le realizzazioni dei socket BSD fanno questa assunzione. @@ -1236,11 +1327,10 @@ chiuso e ritornare immediatamente al processo. Una volta chiamata il socket descriptor non è più utilizzabile dal processo e non può essere usato come argomento per una \func{write} o una \func{read} (anche se l'altro capo della connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti -i dati che ha in coda prima di iniziare la sequenza di chiusura. - -Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile -cambiare questo comportamento, e cosa può essere fatto perché il processo -possa assicurarsi che l'altro capo abbia ricevuto tutti i dati. +i dati che ha in coda prima di iniziare la sequenza di chiusura. Vedremo più +avanti in sez.~\ref{sec:sock_generic_options} come sia possibile cambiare +questo comportamento, e cosa può essere fatto perché il processo possa +assicurarsi che l'altro capo abbia ricevuto tutti i dati. Come per tutti i file descriptor anche per i socket viene mantenuto un numero di riferimenti, per cui se più di un processo ha lo stesso socket aperto @@ -1256,20 +1346,19 @@ descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione sez.~\ref{sec:TCP_shutdown}). - \section{Un esempio elementare: il servizio \textit{daytime}} \label{sec:TCP_daytime_application} Avendo introdotto le funzioni di base per la gestione dei socket, potremo vedere in questa sezione un primo esempio di applicazione elementare che -implementa il servizio \textit{daytime} su TCP, secondo quanto specificato +realizza il servizio \textit{daytime} su TCP, secondo quanto specificato dall'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}. Prima di passare agli esempi del client e del server, inizieremo riesaminando con maggiori dettagli una peculiarità delle funzioni di I/O, già accennata in -sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è -particolarmente rilevante. Passeremo poi ad illustrare gli esempi -dell'implementazione, sia dal lato client, che dal lato server, che si è -realizzato sia in forma iterativa che concorrente. +sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket +è particolarmente rilevante. Passeremo poi ad illustrare gli esempi della +realizzazione, sia dal lato client, che dal lato server, che si è effettuata +sia in forma iterativa che concorrente. \subsection{Il comportamento delle funzioni di I/O} @@ -1340,7 +1429,7 @@ l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un valore negativo in caso di errore, \func{FullRead} restituisce il numero di -byte non letti in caso di end-of-file prematuro. +byte non letti in caso di \textit{end-of-file} prematuro. \subsection{Il client \textit{daytime}} @@ -1409,9 +1498,9 @@ invii sempre una stringa alfanumerica, il formato della stringa non è specificato dallo standard, per cui noi useremo il formato usato dalla funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè qualcosa del tipo: -\begin{verbatim} +\begin{Verbatim} Wed Apr 4 00:53:00 2001\r\n -\end{verbatim} +\end{Verbatim} questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read} in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small 35}) con il solito carattere nullo per poter essere stampata (\texttt{\small @@ -1440,10 +1529,11 @@ Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene fornito direttamente dal \textsl{superdemone} \cmd{inetd}, pertanto basta assicurarsi che esso sia abilitato nel relativo file di configurazione.} possiamo verificare il funzionamento del nostro client, avremo allora: -\begin{verbatim} -[piccardi@gont sources]$ ./daytime 127.0.0.1 +\begin{Console} +[piccardi@gont sources]$ \textbf{./daytime 127.0.0.1} Mon Apr 21 20:46:11 2003 -\end{verbatim}%$ +\end{Console} +%$ e come si vede tutto funziona regolarmente. @@ -1646,14 +1736,14 @@ client. In questa sezione esamineremo un esempio di applicazione client/server un po' più complessa, che usi i socket TCP per una comunicazione in entrambe le direzioni. -Ci limiteremo a fornire una implementazione elementare, che usi solo le -funzioni di base viste finora, ma prenderemo in esame, oltre al comportamento -in condizioni normali, anche tutti i possibili scenari particolari (errori, +Ci limiteremo a fornire una realizzazione elementare, che usi solo le funzioni +di base viste finora, ma prenderemo in esame, oltre al comportamento in +condizioni normali, anche tutti i possibili scenari particolari (errori, sconnessione della rete, crash del client o del server durante la connessione) che possono avere luogo durante l'impiego di un'applicazione di rete, partendo da una versione primitiva che dovrà essere rimaneggiata di volta in volta per poter tenere conto di tutte le evenienze che si possono manifestare nella vita -reale di un'applicazione di rete, fino ad arrivare ad un'implementazione +reale di un'applicazione di rete, fino ad arrivare ad una realizzazione completa. @@ -1923,14 +2013,15 @@ porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo stato con \cmd{netstat}: -\begin{verbatim} -[piccardi@roke piccardi]$ netstat -at +\begin{Console} +[piccardi@roke piccardi]$ \textbf{netstat -at} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 *:echo *:* LISTEN ... -\end{verbatim} %$ +\end{Console} +%$ che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando connessioni da qualunque indirizzo e da qualunque porta e su qualunque interfaccia locale. @@ -1944,12 +2035,12 @@ connessione è stabilita; la \func{connect} ritornerà nel client\footnote{si 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} +\begin{Terminal} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:echo *:* LISTEN tcp 0 0 roke:echo gont:32981 ESTABLISHED -\end{verbatim} +\end{Terminal} mentre per quanto riguarda l'esecuzione dei programmi avremo che: \begin{itemize} \item il client chiama la funzione \code{ClientEcho} che si blocca sulla @@ -1962,14 +2053,15 @@ mentre per quanto riguarda l'esecuzione dei programmi avremo che: \end{itemize} e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo un risultato del tipo: -\begin{verbatim} -[piccardi@roke piccardi]$ ps ax +\begin{Console} +[piccardi@roke piccardi]$ \textbf{ps ax} PID TTY STAT TIME COMMAND ... ... ... ... ... 2356 pts/0 S 0:00 ./echod 2358 pts/1 S 0:00 ./echo 127.0.0.1 2359 pts/0 S 0:00 ./echod -\end{verbatim} %$ +\end{Console} +%$ (dove si sono cancellate le righe inutili) da cui si evidenzia la presenza di tre processi, tutti in stato di \textit{sleep} (vedi tab.~\ref{tab:proc_proc_states}). @@ -1989,21 +2081,23 @@ l'immediata stampa a video. Tutto quello che scriveremo sul client sarà rimandato indietro dal server e ristampato a video fintanto che non concluderemo l'immissione dei dati; una sessione tipica sarà allora del tipo: -\begin{verbatim} -[piccardi@roke sources]$ ./echo 127.0.0.1 +\begin{Console} +[piccardi@roke sources]$ \textbf{./echo 127.0.0.1} Questa e` una prova Questa e` una prova Ho finito Ho finito -\end{verbatim} %$ +\end{Console} +%$ che termineremo inviando un EOF dal terminale (usando la combinazione di tasti ctrl-D, che non compare a schermo); se eseguiamo un \cmd{netstat} a questo punto avremo: -\begin{verbatim} -[piccardi@roke piccardi]$ netstat -at +\begin{Console} +[piccardi@roke piccardi]$ \textbf{netstat -at} tcp 0 0 *:echo *:* LISTEN tcp 0 0 localhost:33032 localhost:echo TIME_WAIT -\end{verbatim} %$ +\end{Console} +%$ con il client che entra in \texttt{TIME\_WAIT}. Esaminiamo allora in dettaglio la sequenza di eventi che porta alla @@ -2046,10 +2140,10 @@ ignorato, non avendo predisposto la ricezione dello stato di terminazione, otterremo che il processo figlio entrerà nello stato di \textit{zombie} (si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà ripetendo il comando \cmd{ps}: -\begin{verbatim} +\begin{Terminal} 2356 pts/0 S 0:00 ./echod 2359 pts/0 Z 0:00 [echod ] -\end{verbatim} +\end{Terminal} Dato che non è il caso di lasciare processi \textit{zombie}, occorrerà ricevere opportunamente lo stato di terminazione del processo (si veda @@ -2081,10 +2175,10 @@ l'esecuzione nel padre ripartirà subito con il ritorno della funzione l'esecuzione del programma in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo previsto questa eventualità il programma considera questo un errore fatale terminando a sua volta con un messaggio del tipo: -\begin{verbatim} -[root@gont sources]# ./echod -i +\begin{Console} +[root@gont sources]# \textbf{./echod -i} accept error: Interrupted system call -\end{verbatim}%# +\end{Console} Come accennato in sez.~\ref{sec:sig_gen_beha} le conseguenze di questo comportamento delle \textit{system call} possono essere superate in due modi @@ -2338,14 +2432,14 @@ Vediamo allora cosa succede nel nostro caso, facciamo partire una connessione con il server e scriviamo una prima riga, poi terminiamo il server con un \texttt{C-c}. A questo punto scriviamo una seconda riga e poi un'altra riga ancora. Il risultato finale della sessione è il seguente: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.141 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.141} Prima riga Prima riga Seconda riga dopo il C-c Altra riga [piccardi@gont sources]$ -\end{verbatim} +\end{Console} Come si vede il nostro client, nonostante la connessione sia stata interrotta prima dell'invio della seconda riga, non solo accetta di inviarla, ma prende @@ -2378,8 +2472,8 @@ il client ed il server; i risultati\footnote{in realtà si è ridotta la lunghezza dell'output rispetto al reale tagliando alcuni dati non necessari alla comprensione del flusso.} prodotti in questa occasione da \cmd{tcpdump} sono allora i seguenti: -\begin{verbatim} -[root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t +\begin{Console} +[root@gont gapil]# \textbf{tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t} tcpdump: listening on eth0 gont.34559 > anarres.echo: S 800922320:800922320(0) win 5840 anarres.echo > gont.34559: S 511689719:511689719(0) ack 800922321 win 5792 @@ -2392,7 +2486,7 @@ anarres.echo > gont.34559: F 12:12(0) ack 12 win 5792 gont.34559 > anarres.echo: . ack 13 win 5840 gont.34559 > anarres.echo: P 12:37(25) ack 13 win 5840 anarres.echo > gont.34559: R 511689732:511689732(0) win 0 -\end{verbatim} +\end{Console} Le prime tre righe vengono prodotte al momento in cui lanciamo il nostro client, e corrispondono ai tre pacchetti del \textit{three way handshake}. @@ -2434,23 +2528,23 @@ ACK da parte del client. A questo punto la connessione dalla parte del server è chiusa, ed infatti se usiamo \cmd{netstat} per controllarne lo stato otterremo che sul server si ha: -\begin{verbatim} -anarres:/home/piccardi# netstat -ant +\begin{Console} +anarres:/home/piccardi# \textbf{netstat -ant} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... ... ... ... ... ... tcp 0 0 192.168.1.141:7 192.168.1.2:34626 FIN_WAIT2 -\end{verbatim} +\end{Console} cioè essa è andata nello stato \texttt{FIN\_WAIT2}, che indica l'avvenuta emissione del segmento FIN, mentre sul client otterremo che essa è andata nello stato \texttt{CLOSE\_WAIT}: -\begin{verbatim} -[root@gont gapil]# netstat -ant +\begin{Console} +[root@gont gapil]# \textbf{netstat -ant} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... ... ... ... ... ... tcp 1 0 192.168.1.2:34582 192.168.1.141:7 CLOSE_WAIT -\end{verbatim} +\end{Console} Il problema è che in questo momento il client è bloccato dentro la funzione \texttt{ClientEcho} nella chiamata a \func{fgets}, e sta attendendo dell'input @@ -2523,13 +2617,14 @@ le funzioni, ed inoltre si verifica la presenza di un eventuale end of file in caso di lettura. Con questa modifica il nostro client echo diventa in grado di accorgersi della chiusura del socket da parte del server, per cui ripetendo la sequenza di operazioni precedenti stavolta otterremo che: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.141 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.141} Prima riga Prima riga Seconda riga dopo il C-c EOF sul socket -\end{verbatim}%$ +\end{Console} +%$ ma di nuovo si tenga presente che non c'è modo di accorgersi della chiusura del socket fin quando non si esegue la scrittura della seconda riga; il protocollo infatti prevede che ci debba essere una scrittura prima di ricevere @@ -2565,13 +2660,14 @@ Cominciamo ad analizzare il primo caso, il crollo della rete. Ripetiamo la nostra sessione di lavoro precedente, lanciamo il client, scriviamo una prima riga, poi stacchiamo il cavo e scriviamo una seconda riga. Il risultato che otterremo è: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.141 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.141} Prima riga Prima riga Seconda riga dopo l'interruzione Errore in lettura: No route to host -\end{verbatim}%$ +\end{Console} +%$ Quello che succede in questo è che il programma, dopo aver scritto la seconda riga, resta bloccato per un tempo molto lungo, prima di dare l'errore @@ -2582,8 +2678,8 @@ del caso precedente, il programma è bloccato nella lettura dal socket. Se poi, come nel caso precedente, usiamo l'accortezza di analizzare il traffico di rete fra client e server con \cmd{tcpdump}, otterremo il seguente risultato: -\begin{verbatim} -[root@gont sources]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t +\begin{Console} +[root@gont sources]# \textbf{tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t} tcpdump: listening on eth0 gont.34685 > anarres.echo: S 1943495663:1943495663(0) win 5840 anarres.echo > gont.34685: S 1215783131:1215783131(0) ack 1943495664 win 5792 @@ -2608,7 +2704,7 @@ arp who-has anarres tell gont arp who-has anarres tell gont arp who-has anarres tell gont ... -\end{verbatim} +\end{Console} 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 @@ -2618,10 +2714,11 @@ 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 successivo, per tentare di ristabilire la connessione. -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 \sysctlrelfile{net/ipv4}{tcp\_retries2} (vedi +Il risultato finale qui dipende dalla realizzazione dello \textit{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 +\sysctlrelfile{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 @@ -2664,8 +2761,8 @@ un valore di tentativi più basso, possiamo evitare la scadenza della \textit{ARP cache} e vedere cosa succede. Così se ad esempio richiediamo 4 tentativi di ritrasmissione, l'analisi di \cmd{tcpdump} ci riporterà il seguente scambio di pacchetti: -\begin{verbatim} -[root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t +\begin{Console} +[root@gont gapil]# \textbf{tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t} tcpdump: listening on eth0 gont.34752 > anarres.echo: S 3646972152:3646972152(0) win 5840 anarres.echo > gont.34752: S 2735190336:2735190336(0) ack 3646972153 win 5792 @@ -2679,19 +2776,20 @@ gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 -\end{verbatim} +\end{Console} e come si vede in questo caso i tentativi di ritrasmissione del pacchetto iniziale sono proprio 4 (per un totale di 5 voci con quello trasmesso la prima volta), ed in effetti, dopo un tempo molto più breve rispetto a prima ed in corrispondenza dell'invio dell'ultimo tentativo, quello che otterremo come errore all'uscita del client sarà diverso, e cioè: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.141 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.141} Prima riga Prima riga Seconda riga dopo l'interruzione Errore in lettura: Connection timed out -\end{verbatim}%$ +\end{Console} +%$ che corrisponde appunto, come ci aspettavamo, alla ricezione di un \errcode{ETIMEDOUT}. @@ -2700,18 +2798,19 @@ fa da server. Al solito lanciamo il nostro client, scriviamo una prima riga per verificare che sia tutto a posto, poi stacchiamo il cavo e riavviamo il server. A questo punto, ritornato attivo il server, scriviamo una seconda riga. Quello che otterremo in questo caso è: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.141 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.141} Prima riga Prima riga Seconda riga dopo l'interruzione Errore in lettura Connection reset by peer -\end{verbatim}%$ +\end{Console} +%$ e l'errore ricevuti da \func{read} stavolta è \errcode{ECONNRESET}. Se al solito riportiamo l'analisi dei pacchetti effettuata con \cmd{tcpdump}, avremo: -\begin{verbatim} -[root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t +\begin{Console} +[root@gont gapil]# \textbf{tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t} tcpdump: listening on eth0 gont.34756 > anarres.echo: S 904864257:904864257(0) win 5840 anarres.echo > gont.34756: S 4254564871:4254564871(0) ack 904864258 win 5792 @@ -2722,7 +2821,7 @@ anarres.echo > gont.34756: P 1:12(11) ack 12 win 5792 gont.34756 > anarres.echo: . ack 12 win 5840 gont.34756 > anarres.echo: P 12:45(33) ack 12 win 5840 anarres.echo > gont.34756: R 4254564883:4254564883(0) win 0 -\end{verbatim} +\end{Console} Ancora una volta i primi sette pacchetti sono gli stessi; ma in questo caso quello che succede dopo lo scambio iniziale è che, non avendo inviato nulla @@ -2974,12 +3073,13 @@ Riprendiamo la situazione affrontata in sez.~\ref{sec:TCP_server_crash}, terminando il server durante una connessione, in questo caso quello che otterremo, una volta scritta una prima riga ed interrotto il server con un \texttt{C-c}, sarà: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.1 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.1} Prima riga Prima riga EOF sul socket -\end{verbatim}%$ +\end{Console} +%$ dove l'ultima riga compare immediatamente dopo aver interrotto il server. Il nostro client infatti è in grado di accorgersi immediatamente che il socket connesso è stato chiuso ed uscire immediatamente. @@ -3002,8 +3102,8 @@ Tra l'altro se si ricollega la rete prima della scadenza del timeout, potremo anche verificare come tutto quello che si era scritto viene poi effettivamente trasmesso non appena la connessione ridiventa attiva, per cui otterremo qualcosa del tipo: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.1 +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.1} Prima riga Prima riga Seconda riga dopo l'interruzione @@ -3012,7 +3112,8 @@ Quarta riga Seconda riga dopo l'interruzione Terza riga Quarta riga -\end{verbatim} +\end{Console} +%$ in cui, una volta riconnessa la rete, tutto quello che abbiamo scritto durante il periodo di disconnessione restituito indietro e stampato immediatamente. @@ -3137,9 +3238,10 @@ nostro client infatti presenta ancora un problema, che nell'uso che finora ne abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo standard input e standard output. Così se eseguiamo: -\begin{verbatim} -[piccardi@gont sources]$ ./echo 192.168.1.1 < ../fileadv.tex > copia -\end{verbatim}%$ +\begin{Console} +[piccardi@gont sources]$ \textbf{./echo 192.168.1.1 < ../fileadv.tex > copia} +\end{Console} +%$ vedremo che il file \texttt{copia} risulta mancare della parte finale. Per capire cosa avviene in questo caso occorre tenere presente come avviene la @@ -3245,8 +3347,8 @@ Seguendo di nuovo le orme di Stevens in \cite{UNP1} vediamo ora come con l'utilizzo dell'I/O multiplexing diventi possibile riscrivere completamente il nostro server \textit{echo} con una architettura completamente diversa, in modo da evitare di dover creare un nuovo processo tutte le volte che si ha una -connessione.\footnote{ne faremo comunque una implementazione diversa rispetto - a quella presentata da Stevens in \cite{UNP1}.} +connessione.\footnote{ne faremo comunque una realizzazione diversa rispetto a + quella presentata da Stevens in \cite{UNP1}.} La struttura del nuovo server è illustrata in fig.~\ref{fig:TCP_echo_multiplex}, in questo caso avremo un solo processo che @@ -3283,11 +3385,11 @@ disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}. In questo caso, una volta aperto e messo in ascolto il socket, tutto quello che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove -connessioni o di dati in arrivo, e processarli immediatamente. Per -implementare lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il -programma usa una tabella dei socket connessi mantenuta nel vettore -\var{fd\_open} dimensionato al valore di \const{FD\_SETSIZE}, ed una variabile -\var{max\_fd} per registrare il valore più alto dei file descriptor aperti. +connessioni o di dati in arrivo, e processarli immediatamente. Per realizzare +lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il programma usa una +tabella dei socket connessi mantenuta nel vettore \var{fd\_open} dimensionato +al valore di \const{FD\_SETSIZE}, ed una variabile \var{max\_fd} per +registrare il valore più alto dei file descriptor aperti. Prima di entrare nel ciclo principale (\texttt{\small 6--56}) la nostra tabella viene inizializzata (\texttt{\small 2}) a zero (valore che @@ -3465,15 +3567,15 @@ pertanto: timeout) viene considerata traffico normale, ma viene segnalata anche dalla condizione \const{POLLERR}. \item la presenza di una nuova connessione su un socket in ascolto può essere - considerata sia traffico normale che prioritario, nel caso di Linux - l'implementazione la classifica come normale. + considerata sia traffico normale che prioritario, nel caso di Linux la + realizzazione dello \textit{stack TCP} la classifica come normale. \end{itemize} -Come esempio dell'uso di \func{poll} proviamo allora a reimplementare il -server \textit{echo} secondo lo schema di fig.~\ref{fig:TCP_echo_multiplex} -usando \func{poll} al posto di \func{select}. In questo caso dovremo fare -qualche modifica, per tenere conto della diversa sintassi delle due funzioni, -ma la struttura del programma resta sostanzialmente la stessa. +Come esempio dell'uso di \func{poll} proviamo allora a riscrivere il server +\textit{echo} secondo lo schema di fig.~\ref{fig:TCP_echo_multiplex} usando +\func{poll} al posto di \func{select}. In questo caso dovremo fare qualche +modifica, per tenere conto della diversa sintassi delle due funzioni, ma la +struttura del programma resta sostanzialmente la stessa. \begin{figure}[!htbp] @@ -3631,3 +3733,4 @@ Da fare. %%% mode: latex %%% TeX-master: "gapil" %%% End: +