\textit{three way handshake}; la successione tipica degli eventi (e dei
\textsl{segmenti}\footnote{si ricordi che il \textsl{segmento} è l'unità
elementare di dati trasmessa dal protocollo TCP al livello successivo; tutti
- i segmenti hanno una intestazione che contiene le informazioni che servono
+ 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
\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 gli header IP e TCP (con il numero di sequenza iniziale e il
- flag SYN) e le opzioni di TCP.
+ 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
client, inoltre anche il server deve inviare il suo SYN al client (e
\index{numeri~di~sequenza|(}
-Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
-riportati in fig.~\ref{fig:TCP_TWH}): per gestire una connessione affidabile
+Si è accennato in precedenza ai \textsl{numeri di sequenza}, che sono anche
+riportati in fig.~\ref{fig:TCP_TWH}: per gestire una connessione affidabile
infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
nella sequenza del flusso corrisponde il primo byte della sezione dati
il primo pacchetto SYN consuma un byte, nel \textit{three way handshake} il
numero di \textit{acknowledge} è sempre pari al numero di sequenza iniziale
incrementato di uno; lo stesso varrà anche (vedi fig.~\ref{fig:TCP_close}) per
-l'\textit{acknowledgement} di un FIN.
+l'\textit{acknowledgement} di un segmento FIN.
\index{numeri~di~sequenza|)}
\itindend{three~way~handshake}
\begin{itemize}
\item \textit{MSS option}, con questa opzione ciascun capo della connessione
annuncia all'altro il massimo ammontare di dati (MMS sta appunto per
- \textit{Maximum Segment Size}) 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}).
+ \textit{Maximum Segment Size}, vedi sez.~\ref{sec:tcp_protocol}) 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}, il protocollo TCP implementa il controllo
- di flusso attraverso una \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{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}
\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
\textit{active close}). Questo comporta l'emissione di un segmento FIN, che
serve ad indicare che si è finito con l'invio dei dati sulla connessione.
-\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
- \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
- altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
- viene segnalato al processo che ha aperto il socket (dopo che ogni altro
+\item L'altro capo della connessione riceve il segmento FIN e dovrà eseguire
+ la \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad
+ ogni altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del
+ FIN viene segnalato al processo che ha aperto il socket (dopo che ogni altro
eventuale dato rimasto in coda è stato ricevuto) come un
- \textit{end-of-file} sulla lettura: questo perché il ricevimento di un FIN
- significa che non si riceveranno altri dati sulla connessione.
+ \textit{end-of-file} sulla lettura: questo perché il ricevimento di un
+ segmento FIN significa che non si riceveranno altri dati sulla connessione.
\item Una volta rilevata l'\textit{end-of-file} anche il secondo processo
chiamerà la funzione \func{close} sul proprio socket, causando l'emissione
di un altro segmento FIN.
-\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
- con un ACK.
+\item L'altro capo della connessione riceverà il segmento FIN conclusivo e
+ risponderà con un ACK.
\end{enumerate}
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro. Questo non è vero sempre
-giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
+giacché in alcune situazioni il FIN del passo 1 è inviato insieme a dei dati.
Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
effettua la chiusura passiva, siano accorpati in un singolo segmento. Come per
il SYN anche il FIN occupa un byte nel numero di sequenza, per cui l'ACK
\label{fig:TCP_close}
\end{figure}
-
Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
possibile che si mantenga un flusso di dati dal capo della connessione che
deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
come utilizzarlo in sez.~\ref{sec:TCP_shutdown}, quando parleremo della
funzione \func{shutdown}.
-La emissione del FIN avviene quando il socket viene chiuso, questo però non
-avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
-alla terminazione di un processo, quando tutti i file vengono chiusi. Questo
-comporta ad esempio che se un processo viene terminato da un segnale tutte le
-connessioni aperte verranno chiuse.
+La emissione del segmento FIN avviene quando il socket viene chiuso, questo
+però non avviene solo per la chiamata esplicita della funzione \func{close},
+ma anche alla terminazione di un processo, quando tutti i file vengono chiusi.
+Questo comporta ad esempio che se un processo viene terminato da un segnale
+tutte le connessioni aperte verranno chiuse.
Infine occorre sottolineare che, benché nella figura (e nell'esempio che
vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
dei due capi della comunicazione (come nell'esempio di
fig.~\ref{fig:TCP_daytime_iter_server_code}), e che anche se il caso più
comune resta quello del client, ci sono alcuni servizi, il più noto dei quali
-è l'HTTP,\footnote{la cosa si applica sempre per la versione 1.0, con le
- versioni successive il default è cambiato.} per i quali è il server ad
-effettuare la chiusura attiva.
+è l'HTTP 1.0 (con le versioni successive il default è cambiato) per i quali è
+il server ad effettuare la chiusura attiva.
\subsection{Un esempio di connessione}
\label{fig:TCP_conn_example}
\end{figure}
-La connessione viene iniziata dal client che annuncia una 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 \textit{Maximum
+ Segment Size} 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
1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
restituisce una risposta (che di nuovo supponiamo stare in un singolo
-segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
-risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
-volte che il server è sufficientemente veloce a costruire la risposta; in
-caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
-risposta.
+segmento). Si noti che l'\textit{acknowledge} della richiesta è mandato
+insieme alla risposta: questo viene chiamato \textit{piggybacking} ed avviene
+tutte le volte che il server è sufficientemente veloce a costruire la
+risposta; in caso contrario si avrebbe prima l'emissione di un ACK e poi
+l'invio della risposta.
Infine si ha lo scambio dei quattro segmenti che terminano la connessione
secondo quanto visto in sez.~\ref{sec:TCP_conn_term}; si noti che il capo della
\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.
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}
in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
+\itindex{Maximum~Segment~Lifetime}
Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
esegue la chiusura attiva resta prima di passare alla chiusura definitiva
della connessione. Il tempo in cui l'applicazione resta in questo stato deve
-essere due volte la MSL (\textit{Maximum Segment Lifetime}).
-
-La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
-sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
-ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
-Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
-IP (per maggiori dettagli vedi sez.~\ref{sec:ip_protocol}), e viene
-decrementato ad ogni passaggio da un router; quando si annulla il pacchetto
-viene scartato. Siccome il numero è ad 8 bit il numero massimo di
-``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
- live}) non è propriamente un limite sul tempo di vita, si stima che un
-pacchetto IP non possa restare nella rete per più di MSL secondi.
-
-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
+essere due volte la \textit{Maximum Segment Lifetime} (da qui in avanti
+abbreviata in MSL).
+
+La MSL è la stima del massimo periodo di tempo in secondi che un pacchetto IP
+può vivere sulla rete. Questo tempo è limitato perché ogni pacchetto IP può
+essere ritrasmesso dai router un numero massimo di volte (detto \textit{hop
+ limit}). Il numero di ritrasmissioni consentito è indicato dal campo TTL
+dell'intestazione di IP (per maggiori dettagli vedi
+sez.~\ref{sec:ip_protocol}), e viene decrementato ad ogni passaggio da un
+router; quando si annulla il pacchetto viene scartato. Siccome il numero è ad
+8 bit il numero massimo di ``\textsl{salti}'' è di 255, pertanto anche se il
+TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
+sua base si può stimare che un pacchetto IP non possa restare nella rete per
+più un certo numero di secondi, che costituisce la \textit{Maximum Segment
+ Lifetime}.
+
+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
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
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
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
\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
\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.
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
+Data una connessione TCP si suole chiamare \textit{socket pair} (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
+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
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.
+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
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
+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
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.
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}
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.
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
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
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
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]
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
projects / gapil.git / blobdiff