%% tcpsock.tex
%%
-%% Copyright (C) 2000-2016 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
ci sono una serie di flag usati per gestire la connessione, come SYN, ACK,
URG, FIN, alcuni di essi, come SYN (che sta per \textit{syncronize})
corrispondono a funzioni particolari del protocollo e danno il nome al
- segmento, (per maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).} di
+ segmento, (per maggiori dettagli si veda sez.~\ref{sec:tcp_protocol}).} di
dati che vengono scambiati) che porta alla creazione di una connessione è la
seguente:
-\begin{enumerate}
+\begin{enumerate*}
\item Il server deve essere preparato per accettare le connessioni in arrivo;
il procedimento si chiama \textsl{apertura passiva} del socket (in inglese
\textit{passive open}). Questo viene fatto chiamando la sequenza di funzioni
funzione \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN
del server inviando un ACK. Alla ricezione di quest'ultimo la funzione
\func{accept} del server ritorna e la connessione è stabilita.
-\end{enumerate}
+\end{enumerate*}
Il procedimento viene chiamato \textit{three way handshake} dato che per
realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
Si è accennato in precedenza ai \textsl{numeri di sequenza}, che sono anche
riportati in fig.~\ref{fig:TCP_TWH}: per gestire una connessione affidabile
-infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
-bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
+infatti il protocollo TCP prevede nell'intestazione la presenza di un numero a
+32 bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
nella sequenza del flusso corrisponde il primo byte della sezione dati
contenuta nel segmento.
all'inizio della connessione e trasmesso con il SYN;
l'\textit{acknowledgement} di ciascun segmento viene effettuato dall'altro
capo della connessione impostando il flag ACK e restituendo nell'apposito
-campo dell'header un \textit{acknowledge number}) pari al numero di sequenza
-che il ricevente si aspetta di ricevere con il pacchetto successivo; dato che
-il primo pacchetto SYN consuma un byte, nel \textit{three way handshake} il
-numero di \textit{acknowledge} è sempre pari al numero di sequenza iniziale
-incrementato di uno; lo stesso varrà anche (vedi fig.~\ref{fig:TCP_close}) per
-l'\textit{acknowledgement} di un segmento FIN.
+campo dell'intestazione un \textit{acknowledge number}) pari al numero di
+sequenza che il ricevente si aspetta di ricevere con il pacchetto successivo;
+dato che il primo pacchetto SYN consuma un byte, nel \textit{three way
+ handshake} il numero di \textit{acknowledge} è sempre pari al numero di
+sequenza iniziale incrementato di uno; lo stesso varrà anche (vedi
+fig.~\ref{fig:TCP_close}) per l'\textit{acknowledgement} di un segmento FIN.
\index{numeri~di~sequenza|)}
\itindend{three~way~handshake}
Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
le cosiddette \textit{TCP options}, da non confondere con le opzioni dei
-socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}; in questo
+socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}. In questo
caso infatti si tratta delle opzioni che vengono trasmesse come parte di un
pacchetto TCP, e non delle funzioni che consentono di impostare i relativi
valori. Queste opzioni vengono inserite fra l'intestazione ed i dati, e
servono a comunicare all'altro capo una serie di parametri utili a regolare la
-connessione. Normalmente vengono usate le seguenti opzioni:
+connessione. Normalmente vengono usate le seguenti opzioni:
-\begin{itemize}
+\begin{itemize*}
\item \textit{MSS option}, con questa opzione ciascun capo della connessione
annuncia all'altro il massimo ammontare di dati (MMS sta appunto per
\textit{Maximum Segment Size}, vedi sez.~\ref{sec:tcp_protocol}) che
poter ottenere il massimo dalla trasmissione.
Per questo esiste un'altra opzione che indica un fattore di scala da
- applicare al valore della finestra annunciata per la connessione corrente
- (espresso come numero di bit cui spostare a sinistra il valore della
- finestra annunciata inserito nel pacchetto). Essendo una nuova opzione per
+ applicare al valore della finestra annunciata per la connessione corrente,
+ espresso come numero di bit cui spostare a sinistra il valore della
+ finestra annunciata inserito nel pacchetto. Essendo una nuova opzione per
garantire la compatibilità con delle vecchie realizzazione del protocollo la
procedura che la attiva prevede come negoziazione che l'altro capo della
connessione riconosca esplicitamente l'opzione inserendola anche lui nel suo
per le connessioni ad alta velocità per evitare possibili corruzioni di dati
dovute a pacchetti perduti che riappaiono; anche questa viene negoziata
all'inizio della connessione come la precedente.
-
-\end{itemize}
+\end{itemize*}
La \textit{MSS option} è generalmente supportata da quasi tutte le
realizzazioni del protocollo, le ultime due opzioni (trattate
segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
caso la successione degli eventi è la seguente:
-\begin{enumerate}
+\begin{enumerate*}
\item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
\textit{active close}). Questo comporta l'emissione di un segmento FIN, che
\item L'altro capo della connessione riceverà il segmento FIN conclusivo e
risponderà con un ACK.
-\end{enumerate}
+\end{enumerate*}
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro. Questo non è vero sempre
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}
+\itindbeg{Maximum~Segment~Lifetime~(MSL)}
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
essere due volte la \textit{Maximum Segment Lifetime} (da qui in avanti
abbreviata in MSL).
-La MSL è la stima del massimo periodo di tempo in secondi che un pacchetto IP
-può vivere sulla rete. Questo tempo è limitato perché ogni pacchetto IP può
-essere ritrasmesso dai router un numero massimo di volte (detto \textit{hop
- limit}). Il numero di ritrasmissioni consentito è indicato dal campo TTL
-dell'intestazione di IP (per maggiori dettagli vedi
+La \textit{Maximum Segment Lifetime} è la stima del massimo periodo di tempo
+in secondi che un pacchetto IP può vivere sulla rete. Questo tempo è limitato
+perché ogni pacchetto IP può essere ritrasmesso dai router un numero massimo
+di volte (detto \textit{hop limit}). Il numero di ritrasmissioni consentito è
+indicato dal campo TTL dell'intestazione di IP (per maggiori dettagli vedi
sez.~\ref{sec:ip_protocol}), e viene decrementato ad ogni passaggio da un
router; quando si annulla il pacchetto viene scartato. Siccome il numero è ad
8 bit il numero massimo di ``\textsl{salti}'' è di 255, pertanto anche se il
TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
sua base si può stimare che un pacchetto IP non possa restare nella rete per
-più un certo numero di secondi, che costituisce la \textit{Maximum Segment
- Lifetime}.
+più un certo numero di secondi, che costituisce la MSL.
+\itindend{Maximum~Segment~Lifetime~(MSL)}
Ogni realizzazione del TCP deve scegliere un valore per la MSL;
l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
-per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
-tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
-nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
-sicuri che lo stesso avvenga per le risposte nella direzione opposta.
+per un periodo di 2 volte la MSL, prima per attendere MSL secondi per essere
+sicuri che tutti i pacchetti duplicati in arrivo siano stati ricevuti e
+scartati, o che nel frattempo siano stati eliminati dalla rete, poi altri MSL
+secondi per essere sicuri che lo stesso avvenga per le risposte nella
+direzione opposta.
In questo modo, prima che venga creata una nuova connessione, il protocollo
TCP si assicura che tutti gli eventuali segmenti residui di una precedente
\cmd{netstat} permette di visualizzare queste informazioni nei campi
\textit{Local Address} e \textit{Foreing Address}.
-
-\subsection{Le porte ed il modello client/server}
-\label{sec:TCP_port_cliserv}
-
Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
che fare con un'applicazione client/server (come quelle che descriveremo in
sez.~\ref{sec:TCP_daytime_application} e sez.~\ref{sec:TCP_echo_application})
In questa sezione descriveremo in maggior dettaglio le varie funzioni che
vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
-precedente in sez.~\ref{sec:sock_creation}.
+precedente in sez.~\ref{sec:sock_creation}. Pur trattandole principalmente dal
+punto di vista dei socket TCP, daremo brevemente conto del loro comportamento
+anche per altri tipi di socket.
\subsection{La funzione \func{bind}}
\begin{errlist}
\item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
sufficienti privilegi.
- \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
+ \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo
+ richiesto oppure quando non si è richiesta un porta specifica per avere
+ una porta effimera non ve ne sono di disponibili nell'intervallo ad esse
+ riservato correntemente in uso.
\item[\errcode{EBADF}] il file descriptor non è valido.
- \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
+ \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato,
+ o \param{addrlen} è sbagliata, o \param{serv\_addr} non è valido per il
+ dominio.
\item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
\end{errlist}
- ed \errval{EFAULT} nel suo significato generico, inoltre per i socket di
+ ed \errval{EFAULT} nel suo significato generico; inoltre per i socket di
tipo \const{AF\_UNIX}:
\begin{errlist}
\item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
disponibile.
\end{errlist}
- ed \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
+ ed \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
\errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.}
\end{funcproto}
\label{sec:TCP_func_connect}
La funzione \funcd{connect} è usata da un client TCP per stabilire la
-connessione con un server TCP,\footnote{di nuovo la funzione è generica e
- supporta vari tipi di socket, la differenza è che per socket senza
- connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si
- limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
- e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
- \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
- TCP il \textit{three way handshake}) della connessione.} il prototipo della
-funzione è il seguente:
+connessione con un server TCP, ma la funzione è generica e supporta vari tipi
+di socket. La differenza è che per socket senza connessione come quelli di
+tipo \const{SOCK\_DGRAM} la sua chiamata si limiterà ad impostare l'indirizzo
+dal quale e verso il quale saranno inviati e ricevuti i pacchetti, mentre per
+socket di tipo \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET} essa attiverà
+la procedura di avvio della connessione (nel caso del TCP il \textit{three way
+ handshake}). Il suo prototipo è il seguente:
\begin{funcproto}{
Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
\func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
-entrambi i socket si trovano con due referenze. Questo fa si che quando il
+entrambi i socket si trovano con due referenze. Questo fa sì che quando il
padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
\subsection{Il client \textit{echo}: prima versione}
\label{sec:TCP_echo_client}
-Il codice della prima versione del client per il servizio \textit{echo},
-disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
+Il codice della prima versione del client per il servizio \textit{echo} (file
+\texttt{TCP\_echo\_first.c}) dei sorgenti allegati alla guida) è riportato in
fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
client per il servizio \textit{daytime} (vedi
sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
Quando si concluderà l'invio di dati mandando un \textit{end-of-file} sullo
\textit{standard input} si avrà il ritorno di \func{fgets} con un puntatore
-nullo (si riveda quanto spiegato in sez.~\ref{sec:file_line_io}) e la
+nullo (si riveda quanto spiegato in sez.~\ref{sec:file_unformatted_io}) e la
conseguente uscita dal ciclo; al che la subroutine ritorna ed il nostro
programma client termina.
Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
niente fintanto che non si preme il tasto di a capo (si ricordi quanto detto
-in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale). Solo
-allora \func{fgets} ritornerà ed il client scriverà quanto immesso dal
+in sez.~\ref{sec:file_unformatted_io} a proposito dell'I/O su terminale).
+Solo allora \func{fgets} ritornerà ed il client scriverà quanto immesso dal
terminale sul socket, per poi passare a rileggere quanto gli viene inviato
all'indietro dal server, che a sua volta sarà inviato sullo \textit{standard
output}, che nel caso ne provoca l'immediata stampa a video.
errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
\end{itemize*}
-Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
+Infine c'è una sola condizione che fa sì che \func{select} ritorni segnalando
che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
condizione di eccezione pendente, e cioè la ricezione sul socket di
\textsl{dati urgenti} (o \textit{out-of-band}), una caratteristica specifica
quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
dei programmi, se infatti si sa che una applicazione non è in grado di fare
niente fintanto che non può ricevere o inviare una certa quantità di dati, si
-possono utilizzare questi valori per far si che \func{select} ritorni solo
+possono utilizzare questi valori per far sì che \func{select} ritorni solo
quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
controllo è utile di norma solo per la lettura, in quanto in genere le
operazioni di scrittura sono già controllate dall'applicazione, che sa
\includecodesample{listati/select_echod.c}
\end{minipage}
\normalsize
- \caption{La sezione principale del codice della nuova versione di server
- \textit{echo} basati sull'uso della funzione \func{select}.}
+ \caption{La sezione principale della nuova versione di server
+ \textit{echo} basato sull'uso della funzione \func{select}.}
\label{fig:TCP_SelectEchod}
\end{figure}
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
+Prima di entrare nel ciclo principale (\texttt{\small 5--53}) la nostra
tabella viene inizializzata (\texttt{\small 2}) a zero (valore che
utilizzeremo come indicazione del fatto che il relativo file descriptor non è
aperto), mentre il valore massimo (\texttt{\small 3}) per i file descriptor
l'unico file aperto, oltre i tre standard, e pertanto avrà il valore più alto,
che verrà anche (\texttt{\small 4}) inserito nella tabella.
-La prima sezione (\texttt{\small 7--10}) del ciclo principale esegue la
+La prima sezione (\texttt{\small 6--8}) del ciclo principale esegue la
costruzione del \textit{file descriptor set} \var{fset} in base ai socket
connessi in un certo momento; all'inizio ci sarà soltanto il socket in ascolto
ma nel prosieguo delle operazioni verranno utilizzati anche tutti i socket
connessi registrati nella tabella \var{fd\_open}. Dato che la chiamata di
\func{select} modifica il valore del \textit{file descriptor set} è necessario
-ripetere (\texttt{\small 7}) ogni volta il suo azzeramento per poi procedere
-con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket trovati
+ripetere (\texttt{\small 6}) ogni volta il suo azzeramento per poi procedere
+con il ciclo (\texttt{\small 7--8}) in cui si impostano i socket trovati
attivi.
Per far questo si usa la caratteristica dei file descriptor, descritta in
sez.~\ref{sec:file_open_close}, per cui il kernel associa sempre ad ogni nuovo
file il file descriptor con il valore più basso disponibile. Questo fa sì che
-si possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo,
+si possa eseguire il ciclo (\texttt{\small 7}) a partire da un valore minimo,
che sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd},
fino al valore massimo di \var{max\_fd} che dovremo aver cura di tenere
-aggiornato. Dopo di che basterà controllare (\texttt{\small 9}) nella nostra
+aggiornato. Dopo di che basterà controllare (\texttt{\small 8}) nella nostra
tabella se il file descriptor è in uso o meno,\footnote{si tenga presente che
benché il kernel assegni sempre il primo valore libero, si potranno sempre
avere dei \textsl{buchi} nella nostra tabella dato che nelle operazioni i
set} potremo chiamare \func{select} per fargli osservare lo stato degli
stessi (in lettura, presumendo che la scrittura sia sempre consentita). Come
per il precedente esempio di sez.~\ref{sec:TCP_child_hand}, essendo questa
-l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
-eseguiremo (\texttt{\small 11--12}) all'interno di un ciclo di \code{while}
+l'unica funzione che può bloccarsi ed essere interrotta da un segnale, la
+eseguiremo (\texttt{\small 9--10}) all'interno di un ciclo di \code{while},
che la ripete indefinitamente qualora esca con un errore di \errcode{EINTR}.
-Nel caso invece di un errore normale si provvede (\texttt{\small 13--16}) ad
-uscire stampando un messaggio di errore.
-
-Se invece la funzione ritorna normalmente avremo in \var{n} il numero di
-socket da controllare. Nello specifico si danno due possibili casi diversi per
-cui \func{select} può essere ritornata: o si è ricevuta una nuova connessione
-ed è pronto il socket in ascolto, sul quale si può eseguire \func{accept}, o
-c'è attività su uno dei socket connessi, sui quali si può eseguire
-\func{read}.
-
-Il primo caso viene trattato immediatamente (\texttt{\small 17--26}): si
-controlla (\texttt{\small 17}) che il socket in ascolto sia fra quelli attivi,
-nel qual caso anzitutto (\texttt{\small 18}) se ne decrementa il numero in
-\var{n}. Poi, inizializzata (\texttt{\small 19}) la lunghezza della struttura
-degli indirizzi, si esegue \func{accept} per ottenere il nuovo socket connesso
-controllando che non ci siano errori (\texttt{\small 20--23}). In questo caso
-non c'è più la necessità di controllare per interruzioni dovute a segnali, in
-quanto siamo sicuri che \func{accept} non si bloccherà. Per completare la
-trattazione occorre a questo punto aggiungere (\texttt{\small 24}) il nuovo
-file descriptor alla tabella di quelli connessi, ed inoltre, se è il caso,
-aggiornare (\texttt{\small 25}) il valore massimo in \var{max\_fd}.
+Nel caso invece di un errore normale si provvede (\texttt{\small 11--14}) ad
+uscire dal programma stampando un messaggio di errore.
+
+Infine quando la funzione ritorna normalmente avremo in \var{n} il numero di
+socket da controllare. Nello specifico si danno due casi per cui \func{select}
+può ritornare: o si è ricevuta una nuova connessione ed è pronto il socket in
+ascolto, sul quale si può eseguire \func{accept}, o c'è attività su uno dei
+socket connessi, sui quali si può eseguire \func{read}.
+
+Il primo caso viene trattato immediatamente (\texttt{\small 15--24}): si
+controlla (\texttt{\small 15}) che il socket in ascolto sia fra quelli attivi,
+nel qual caso anzitutto (\texttt{\small 16}) se ne decrementa il numero
+mantenuto nella variabile \var{n}. Poi, inizializzata (\texttt{\small 17}) la
+lunghezza della struttura degli indirizzi, si esegue \func{accept} per
+ottenere il nuovo socket connesso, controllando che non ci siano errori
+(\texttt{\small 18--21}). In questo caso non c'è più la necessità di
+controllare per interruzioni dovute a segnali, in quanto siamo sicuri che
+\func{accept} non si bloccherà. Per completare la trattazione occorre a questo
+punto aggiungere (\texttt{\small 22}) il nuovo file descriptor alla tabella di
+quelli connessi, ed inoltre, se è il caso, aggiornare (\texttt{\small 23}) il
+valore massimo in \var{max\_fd}.
Una volta controllato l'arrivo di nuove connessioni si passa a verificare se
ci sono dati sui socket connessi, per questo si ripete un ciclo
-(\texttt{\small 29--55}) fintanto che il numero di socket attivi \var{n} resta
-diverso da zero; in questo modo se l'unico socket con attività era quello
-connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
-saltato e si ritornerà immediatamente, ripetuta l'inizializzazione del
-\textit{file descriptor set} con i nuovi valori nella tabella, alla chiamata
-di \func{accept}.
+(\texttt{\small 26--52}) fintanto che il numero di socket attivi indicato
+dalla variabile \var{n} resta diverso da zero. In questo modo, se l'unico
+socket con attività era quello connesso, avendola opportunamente decrementata
+in precedenza, essa risulterà nulla, pertanto il ciclo di verifica verrà
+saltato e si ritornerà all'inzizio del ciclo principale, ripetendo, dopo
+l'inizializzazione del \textit{file descriptor set} con i nuovi valori nella
+tabella, la chiamata di \func{select}.
Se il socket attivo non è quello in ascolto, o ce ne sono comunque anche
altri, il valore di \var{n} non sarà nullo ed il controllo sarà
-eseguito. Prima di entrare nel ciclo comunque si inizializza (\texttt{\small
- 28}) il valore della variabile \var{i}, che useremo come indice nella
-tabella, \var{fd\_open} al valore minimo, corrispondente al file descriptor
-del socket in ascolto.
+eseguito. Prima di entrare nel ciclo di veridica comunque si inizializza
+(\texttt{\small 25}) il valore della variabile \var{i}, che useremo come
+indice nella tabella \var{fd\_open}, al valore minimo, corrispondente al file
+descriptor del socket in ascolto.
-Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
+Il primo passo (\texttt{\small 27}) nella verifica è incrementare il valore
dell'indice \var{i} per posizionarsi sul primo valore possibile per un file
descriptor associato ad un eventuale socket connesso, dopo di che si controlla
-(\texttt{\small 31}) se questo è nella tabella dei socket connessi, chiedendo
+(\texttt{\small 28}) se questo è nella tabella dei socket connessi, chiedendo
la ripetizione del ciclo in caso contrario. Altrimenti si passa a verificare
-(\texttt{\small 32}) se il file descriptor corrisponde ad uno di quelli
-attivi, e nel caso si esegue (\texttt{\small 33}) una lettura, uscendo con un
-messaggio in caso di errore (\texttt{\small 34--38}).
-
-Se (\texttt{\small 39}) il numero di byte letti \var{nread} è nullo si è in
-presenza di un \textit{end-of-file}, indice che una connessione che si è
-chiusa, che deve essere trattato (\texttt{\small 39--48}) opportunamente. Il
-primo passo è chiudere (\texttt{\small 40}) anche il proprio capo del socket e
-rimuovere (\texttt{\small 41}) il file descriptor dalla tabella di quelli
-aperti, inoltre occorre verificare (\texttt{\small 42}) se il file descriptor
+(\texttt{\small 29}) se il file descriptor corrisponde ad uno di quelli
+attivi, e nel caso si esegue (\texttt{\small 30}) una lettura, uscendo con un
+messaggio in caso di errore (\texttt{\small 31--35}).
+
+Se (\texttt{\small 36}) il numero di byte letti \var{nread} è nullo si è in
+presenza di una \textit{end-of-file}, indice che una connessione che si è
+chiusa, che deve essere trattata (\texttt{\small 36--45}) opportunamente. Il
+primo passo è chiudere (\texttt{\small 37}) anche il proprio capo del socket e
+rimuovere (\texttt{\small 38}) il file descriptor dalla tabella di quelli
+aperti, inoltre occorre verificare (\texttt{\small 39}) se il file descriptor
chiuso è quello con il valore più alto, nel qual caso occorre trovare
-(\texttt{\small 42--46}) il nuovo massimo, altrimenti (\texttt{\small 47}) si
+(\texttt{\small 39--43}) il nuovo massimo, altrimenti (\texttt{\small 44}) si
può ripetere il ciclo da capo per esaminare (se ne restano) ulteriori file
descriptor attivi.
file descriptor attivi viene fatta a partire dal valore più basso, questo
significa che siamo anche arrivati alla fine della scansione, per questo
possiamo utilizzare direttamente il valore dell'indice \var{i} con un ciclo
-all'indietro (\texttt{\small 43}) che trova il primo valore per cui la tabella
-presenta un file descriptor aperto, e lo imposta (\texttt{\small 44}) come
-nuovo massimo, per poi tornare (\texttt{\small 44}) al ciclo principale con un
+all'indietro (\texttt{\small 40}) che trova il primo valore per cui la tabella
+presenta un file descriptor aperto, e lo imposta (\texttt{\small 41}) come
+nuovo massimo, per poi tornare (\texttt{\small 42}) al ciclo principale con un
\code{break}, e rieseguire \func{select}.
Se infine si sono effettivamente letti dei dati dal socket (ultimo caso
-rimasto) si potrà invocare immediatamente (\texttt{\small 49})
+rimasto) si potrà invocare immediatamente (\texttt{\small 46})
\func{FullWrite} per riscriverli indietro sul socket stesso, avendo cura di
-uscire con un messaggio in caso di errore (\texttt{\small 50--53}). Si noti
+uscire con un messaggio in caso di errore (\texttt{\small 47--50}). Si noti
che nel ciclo si esegue una sola lettura, contrariamente a quanto fatto con la
precedente versione (si riveda il codice di fig.~\ref{fig:TCP_ServEcho_second})
in cui si continuava a leggere fintanto che non si riceveva un
\includecodesample{listati/poll_echod.c}
\end{minipage}
\normalsize
- \caption{La sezione principale del codice della nuova versione di server
- \textit{echo} basati sull'uso della funzione \func{poll}.}
+ \caption{La sezione principale della nuova versione di server
+ \textit{echo} basato sull'uso della funzione \func{poll}.}
\label{fig:TCP_PollEchod}
\end{figure}
Dopo di che si preimposta (\texttt{\small 3}) il valore \var{max\_fd} del file
descriptor aperto con valore più alto a quello del socket in ascolto (al
momento l'unico), e si provvede (\texttt{\small 4--7}) ad inizializzare le
-strutture, disabilitando (\texttt{\small 5}) l'osservazione con un valore
-negativo del campo \var{fd} ma predisponendo (\texttt{\small 6}) il campo
+strutture, disabilitando l'osservazione (\texttt{\small 5}) con un valore
+negativo del campo \var{fd}, ma predisponendo (\texttt{\small 6}) il campo
\var{events} per l'osservazione dei dati normali con \const{POLLRDNORM}.
Infine (\texttt{\small 8}) si attiva l'osservazione del socket in ascolto
inizializzando la corrispondente struttura. Questo metodo comporta, in
socket in ascolto.
Una volta completata l'inizializzazione tutto il lavoro viene svolto
-all'interno del ciclo principale \texttt{\small 10--55}) che ha una struttura
+all'interno del ciclo principale \texttt{\small 9--53}) che ha una struttura
sostanzialmente identica a quello usato per il precedente esempio basato su
-\func{select}. La prima istruzione (\texttt{\small 11--12}) è quella di
-eseguire \func{poll} all'interno di un ciclo che la ripete qualora venisse
-interrotta da un segnale, da cui si esce soltanto quando la funzione ritorna,
-restituendo nella variabile \var{n} il numero di file descriptor trovati
-attivi. Qualora invece si sia ottenuto un errore si procede (\texttt{\small
- 13--16}) alla terminazione immediata del processo provvedendo a stampare una
-descrizione dello stesso.
+\func{select}. La prima istruzione (\texttt{\small 10}) è quella di eseguire
+\func{poll} all'interno di un ciclo che la ripete qualora venisse interrotta
+da un segnale, da cui si esce soltanto quando la funzione ritorna restituendo
+nella variabile \var{n} il numero di file descriptor trovati attivi. Qualora
+invece si sia ottenuto un errore si procede (\texttt{\small 11--14}) alla
+terminazione immediata del processo provvedendo a stampare una descrizione
+dello stesso.
Una volta ottenuta dell'attività su un file descriptor si hanno di nuovo due
-possibilità. La prima possibilità è che ci sia attività sul socket in ascolto,
-indice di una nuova connessione, nel qual caso si controlla (\texttt{\small
- 17}) se il campo \var{revents} della relativa struttura è attivo; se è così
-si provvede (\texttt{\small 18}) a decrementare la variabile \var{n} (che
-assume il significato di numero di file descriptor attivi rimasti da
-controllare) per poi (\texttt{\small 19--23}) effettuare la chiamata ad
-\func{accept}, terminando il processo in caso di errore. Se la chiamata ad
-\func{accept} ha successo si procede attivando (\texttt{\small 24}) la
-struttura relativa al nuovo file descriptor da essa ottenuto, modificando
-(\texttt{\small 24}) infine quando necessario il valore massimo dei file
-descriptor aperti mantenuto in \var{max\_fd}.
+possibilità. La prima è che ci sia attività sul socket in ascolto, indice di
+una nuova connessione, nel qual caso si controlla (\texttt{\small 17}) se il
+campo \var{revents} della relativa struttura è attivo; se è così si provvede
+(\texttt{\small 16}) a decrementare la variabile \var{n} (che assume il
+significato di numero di file descriptor attivi rimasti da controllare) per
+poi (\texttt{\small 17--21}) effettuare la chiamata ad \func{accept},
+terminando il processo in caso di errore. Se la chiamata ad \func{accept} ha
+successo si procede attivando (\texttt{\small 22}) la struttura relativa al
+nuovo file descriptor da essa ottenuto, modificando (\texttt{\small 23})
+infine quando necessario il valore massimo dei file descriptor aperti
+mantenuto in \var{max\_fd}.
La seconda possibilità è che vi sia dell'attività su uno dei socket aperti in
-precedenza, nel qual caso si inizializza (\texttt{\small 27}) l'indice \var{i}
+precedenza, nel qual caso si inizializza (\texttt{\small 25}) l'indice \var{i}
del vettore delle strutture \struct{pollfd} al valore del socket in ascolto,
dato che gli ulteriori socket aperti avranno comunque un valore superiore. Il
-ciclo (\texttt{\small 28--54}) prosegue fintanto che il numero di file
+ciclo (\texttt{\small 26--52}) prosegue fintanto che il numero di file
descriptor attivi, mantenuto nella variabile \var{n}, è diverso da zero. Se
pertanto ci sono ancora socket attivi da individuare si comincia con
-l'incrementare (\texttt{\small 30}) l'indice e controllare (\texttt{\small
- 31}) se corrisponde ad un file descriptor in uso analizzando il valore del
+l'incrementare (\texttt{\small 27}) l'indice e controllare (\texttt{\small
+ 28}) se corrisponde ad un file descriptor in uso analizzando il valore del
campo \var{fd} della relativa struttura e chiudendo immediatamente il ciclo
qualora non lo sia. Se invece il file descriptor è in uso si verifica
-(\texttt{\small 31}) se c'è stata attività controllando il campo
-\var{revents}.
+(\texttt{\small 29}) se c'è stata attività controllando il campo
+\var{revents}.
Di nuovo se non si verifica la presenza di attività il ciclo si chiude subito,
-altrimenti si provvederà (\texttt{\small 32}) a decrementare il numero \var{n}
-di file descriptor attivi da controllare e ad eseguire (\texttt{\small 33}) la
-lettura, ed in caso di errore (\texttt{\small 34--37}) al solito lo si
+altrimenti si provvederà (\texttt{\small 30}) a decrementare il numero \var{n}
+di file descriptor attivi da controllare e ad eseguire (\texttt{\small 31}) la
+lettura, ed in caso di errore (\texttt{\small 32--35}) al solito lo si
notificherà uscendo immediatamente. Qualora invece si ottenga una condizione
-di \textit{end-of-file} (\texttt{\small 38--47}) si provvederà a chiudere
-(\texttt{\small 39}) anche il nostro capo del socket e a marcarlo
-(\texttt{\small 40}) nella struttura ad esso associata come inutilizzato.
-Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo
-valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il
+di \textit{end-of-file} (\texttt{\small 36--45}) si provvederà a chiudere
+(\texttt{\small 37}) anche il nostro capo del socket e a marcarlo
+(\texttt{\small 38}) come inutilizzato nella struttura ad esso associata.
+Infine dovrà essere ricalcolato (\texttt{\small 39--43}) un eventuale nuovo
+valore di \var{max\_fd}. L'ultimo passo è chiudere (\texttt{\small 44}) il
ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro
sul socket.
-Se invece si sono letti dei dati si provvede (\texttt{\small 48}) ad
+Se invece si sono letti dei dati si provvede (\texttt{\small 46}) ad
effettuarne la riscrittura all'indietro, con il solito controllo ed eventuale
-uscita e notifica in caso di errore (\texttt{\small 49--52}).
+uscita e notifica in caso di errore (\texttt{\small 47--51}).
Come si può notare la logica del programma è identica a quella vista in
fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select};
considerazioni finali di sez.~\ref{sec:TCP_serv_select}.
-\subsection{\textit{I/O multiplexing} con \textit{epoll}}
-\label{sec:TCP_serv_epoll}
+%\subsection{\textit{I/O multiplexing} con \textit{epoll}}
+%\label{sec:TCP_serv_epoll}
-Da fare.
+%Da fare.
% TODO fare esempio con epoll
projects / gapil.git / blobdiff