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} (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}.
+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}
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.
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
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
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}
\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
\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
\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
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 è
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
\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}.
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}
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
-realizzazioni.
+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
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 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}).
+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
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
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
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 realizzazioni dei
+\ctyp{int *} come prima dello standard, perché tutte le realizzazioni dei
socket BSD fanno questa assunzione.
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
sez.~\ref{sec:TCP_shutdown}).
-
\section{Un esempio elementare: il servizio \textit{daytime}}
\label{sec:TCP_daytime_application}
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}}
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
- 36}) sullo standard output con l'uso di \func{fputs}.
+ 36}) sullo \textit{standard output} con l'uso di \func{fputs}.
Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
programma stesso.
Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
- fornito direttamente dal \textsl{superdemone} \cmd{inetd}, pertanto basta
+ fornito direttamente dal \textsl{superdemone} \cmd{xinetd}, 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.
La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
\struct{sockaddr\_in}. Anche in questo caso (\texttt{\small 28}) si usa la
-porta standard del servizio daytime, ma come indirizzo IP si usa
-(\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
+porta standard del servizio \textit{daytime}, ma come indirizzo IP si usa
+(\texttt{\small 29}) il valore predefinito \const{INET\_ANY}, che corrisponde
all'indirizzo generico.
Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
\textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
-modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
- ciclo principale.} per tener conto di quanto illustrato in
+modifiche (come una chiamata a \func{daemon} prima dell'inizio del ciclo
+principale) per tener conto di quanto illustrato in
sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
di gestione della terminazione del processo, dato che tutti i file descriptor
vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
la porta da cui il client effettua la connessione, che in un secondo tempo,
-(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
-output.
+(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo
+\textit{standard output}.
Quando \func{accept} ritorna il server chiama la funzione \func{fork}
(\texttt{\small 27--31}) per creare il processo figlio che effettuerà
estremamente breve e verrà senz'altro scritta in un singolo segmento.
Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
-provvede anche (\texttt{\small 40--43}) a stampare sullo standard output
-l'indirizzo e la porta da cui il client ha effettuato la connessione, usando i
-valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
-opportune conversioni con \func{inet\_ntop} e \func{ntohs}.
+provvede anche (\texttt{\small 40--43}) a stampare sullo \textit{standard
+ output} l'indirizzo e la porta da cui il client ha effettuato la
+connessione, usando i valori contenuti nelle strutture restituite da
+\func{accept}, eseguendo le opportune conversioni con \func{inet\_ntop} e
+\func{ntohs}.
Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
non si sia gestita né la terminazione del processo né il suo uso come demone,
complessi.
-
\section{Un esempio più completo: il servizio \textit{echo}}
\label{sec:TCP_echo_application}
\subsection{Il servizio \textit{echo}}
\label{sec:TCP_echo}
-
Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
dall'\href{http://www.ietf.org/rfc/rfc862.txt}{RFC~862}. Come dice il nome il
servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
-il primo stabilisce che una volta stabilita la connessione ogni dato in
+qil primo stabilisce che una volta stabilita la connessione ogni dato in
ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
chiude la connessione. Al servizio è assegnata la porta riservata 7.
Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
-caratteri dallo standard input e la scrive sul server. A sua volta il server
-leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
-compito del client leggere la risposta del server e stamparla sullo standard
-output.
+caratteri dallo \textit{standard input} e la scrive sul server. A sua volta il
+server leggerà la linea dalla connessione e la riscriverà immutata
+all'indietro. Sarà compito del client leggere la risposta del server e
+stamparla sullo \textit{standard output}.
\subsection{Il client \textit{echo}: prima versione}
sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
è sostanzialmente identica, a parte l'uso di una porta diversa.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/TCP_echo_first.c}
Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
riga di comando. Una volta dichiarate le variabili, si prosegue
-(\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
+(\texttt{\small 10--13}) con la creazione del socket con l'usuale controllo
degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
\textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
Completata la connessione, per gestire il funzionamento del protocollo si usa
la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
fig.~\ref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
-comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
-scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
-risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche
-il programma termina.
+comunicazione, leggendo una riga alla volta dallo \textit{standard input}
+\file{stdin}, scrivendola sul socket e ristampando su \file{stdout} quanto
+ricevuto in risposta dal server. Al ritorno dalla funzione (\texttt{\small
+ 30--31}) anche il programma termina.
La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per
gestire i dati inviati e letti sul socket. La comunicazione viene gestita
\label{fig:TCP_client_echo_sub}
\end{figure}
-Quando si concluderà l'invio di dati mandando un end-of-file sullo 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 conseguente uscita dal
-ciclo; al che la subroutine ritorna ed il nostro programma client termina.
+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
+conseguente uscita dal ciclo; al che la subroutine ritorna ed il nostro
+programma client termina.
Si può effettuare una verifica del funzionamento del client abilitando il
-servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
+servizio \textit{echo} nella configurazione di \cmd{xinetd} sulla propria
macchina ed usandolo direttamente verso di esso in locale, vedremo in
dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
programma, usato però con la nostra versione del server \textit{echo}, che
\label{sec:TCPsimp_server_main}
La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
-è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
-per il client anche il server è stato diviso in un corpo principale,
-costituito dalla funzione \code{main}, che è molto simile a quello visto nel
-precedente esempio per il server del servizio \textit{daytime} di
+è riportata in fig.~\ref{fig:TCP_echo_server_first_code} e
+fig.~\ref{fig:TCP_echo_server_first_main}. Come abbiamo fatto per il client
+anche il server è stato diviso in un corpo principale, costituito dalla
+funzione \code{main}, che è molto simile a quello visto nel precedente esempio
+per il server del servizio \textit{daytime} di
sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
\code{ServEcho} che si cura della gestione del servizio.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/TCP_echod_first.c}
+ \includecodesample{listati/TCP_echod_first_init.c}
\end{minipage}
\normalsize
- \caption{Codice del corpo principale della prima versione del server
+ \caption{Codice di inizializzatione della prima versione del server
per il servizio \textit{echo}.}
\label{fig:TCP_echo_server_first_code}
\end{figure}
(\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
processo come demone.
-A questo punto il programma riprende di nuovo lo schema già visto usato dal
-server per il servizio \textit{daytime}, con l'unica differenza della chiamata
-alla funzione \code{PrintErr}, riportata in fig.~\ref{fig:TCP_PrintErr}, al
-posto di \func{perror} per la stampa degli errori.
-
-Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si
-esegue indefinitamente il ciclo principale (\texttt{\small 42--59}).
-All'interno di questo si ricevono (\texttt{\small 43--47}) le connessioni,
-creando (\texttt{\small 48--51}) un processo figlio per ciascuna di esse.
-Quest'ultimo (\texttt{\small 52--56}), chiuso (\texttt{\small 53}) il
-\textit{listening socket}, esegue (\texttt{\small 54}) la funzione di gestione
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/TCP_echod_first_main.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice di inizializzatione della prima versione del server
+ per il servizio \textit{echo}.}
+ \label{fig:TCP_echo_server_first_main}
+\end{figure}
+
+A questo punto il programma prosegue nel ciclo principale, illustrato in
+fig.~\ref{fig:TCP_echo_server_first_main}, usando lo schema già visto in
+precedenza per server per il servizio \textit{daytime}, con l'unica differenza
+della chiamata alla funzione \code{PrintErr}, riportata in
+fig.~\ref{fig:TCP_PrintErr}, al posto di \func{perror} per la stampa degli
+errori.
+
+Si inizia con il porre (\texttt{\small 3--6}) in ascolto il socket, e poi si
+esegue indefinitamente il ciclo principale (\texttt{\small 7--26}).
+All'interno di questo si ricevono (\texttt{\small 9--12}) le connessioni,
+creando (\texttt{\small 13--16}) un processo figlio per ciascuna di esse.
+Quest'ultimo (\texttt{\small 17--21}), chiuso (\texttt{\small 18}) il
+\textit{listening socket}, esegue (\texttt{\small 19}) la funzione di gestione
del servizio \code{ServEcho}, ed al ritorno di questa esce (\texttt{\small
- 55}).
+ 20}).
-Il padre invece si limita (\texttt{\small 57}) a chiudere il \textit{connected
+Il padre invece si limita (\texttt{\small 22}) a chiudere il \textit{connected
socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
questo modo si ha un server concorrente. La terminazione del padre non è
gestita esplicitamente, e deve essere effettuata inviando un segnale al
come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
in fig.~\ref{fig:TCP_PrintErr}.
-In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
-(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
- 3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
-messaggio di errore fornito come argomento sui log di sistema. Se invece si è
-in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
-(\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
-standard error.
-
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/PrintErr.c}
\end{minipage}
\normalsize
- \caption{Codice della funzione \code{PrintErr} per la
- generalizzazione della stampa degli errori sullo standard input o
- attraverso il \texttt{syslog}.}
+ \caption{Codice della funzione \code{PrintErr} per la generalizzazione della
+ stampa degli errori sullo \textit{standard input} o attraverso il
+ \texttt{syslog}.}
\label{fig:TCP_PrintErr}
\end{figure}
+
+In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
+(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
+ 3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
+messaggio di errore fornito come argomento sui log di sistema. Se invece si è
+in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
+(\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
+\textit{standard error}.
+
La gestione del servizio \textit{echo} viene effettuata interamente nella
funzione \code{ServEcho}, il cui codice è mostrato in
fig.~\ref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
di un ciclo (\texttt{\small 6--13}). I dati inviati dal client vengono letti
(\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
-in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
-funzione \func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_code}) che
-si incarica di tenere conto automaticamente della possibilità che non tutti i
+in arrivo.
+
+La riscrittura (\texttt{\small 7}) viene invece gestita dalla funzione
+\func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_code}) che si
+incarica di tenere conto automaticamente della possibilità che non tutti i
dati di cui è richiesta la scrittura vengano trasmessi con una singola
\func{write}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/ServEcho_first.c}
In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
valore nullo in caso di successo) si provvede (\texttt{\small 8--10}) a
stampare il relativo messaggio con \func{PrintErr}. Quando il client chiude
-la connessione il ricevimento del FIN fa ritornare la \func{read} con un
-numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il ritorno
-(\texttt{\small 12}) della funzione, che a sua volta causa la terminazione del
-processo figlio.
+la connessione il ricevimento del segmento FIN fa ritornare la \func{read} con
+un numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il
+ritorno (\texttt{\small 12}) della funzione, che a sua volta causa la
+terminazione del processo figlio.
-\subsection{L'avvio e il funzionamento normale}
+\subsection{L'avvio e il funzionamento ordinario}
\label{sec:TCP_echo_startup}
Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
di considerare in dettaglio le varie problematiche che si possono incontrare
nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
-modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
-che avviene nelle varie situazioni limite, da una parte potremo approfondire
-la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
-necessarie per essere in grado di scrivere applicazioni robuste, in grado di
-gestire anche i casi limite.
-
-Il primo passo è compilare e lanciare il server (da root, per poter usare la
-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
+modalità di funzionamento ordinarie, all'avvio e alla terminazione, e di
+quello che avviene nelle varie situazioni limite, da una parte potremo
+approfondire la comprensione del protocollo TCP/IP e dall'altra ricavare le
+indicazioni necessarie per essere in grado di scrivere applicazioni robuste,
+in grado di gestire anche i casi limite.
+
+Il primo passo è compilare e lanciare il server (usando l'utente di
+amministrazione, per poter usare la porta 7 che è riservata). All'avvio 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{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.
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
\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}).
Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
-niente fin tanto che non si prema 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 sul socket, per
-poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
-a sua volta sarà inviato sullo standard output, che nel caso ne provoca
-l'immediata stampa a video.
+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
+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.
\subsection{La conclusione normale}
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
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 <defunct>]
-\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
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
cosa che invece nel caso di Linux viene sempre fatta.} anche quando questa è
presente, non è detto possa essere usata con \func{accept}.
-
La portabilità nella gestione dei segnali però viene al costo di una
riscrittura parziale del server, la nuova versione di questo, in cui si sono
introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
gestione di tutte queste opzioni, che può essere trovata nel sorgente del
programma.
-\begin{figure}[!htbp]
+\begin{figure}[!htb ]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/TCP_echod_second.c}
altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
altrimenti il programma prosegue.
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/ServEcho_second.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della seconda versione della funzione \code{ServEcho} per la
+ gestione del servizio \textit{echo}.}
+ \label{fig:TCP_ServEcho_second}
+\end{figure}
+
Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
(\texttt{\small 32--40}) di aiuto per il debug del programma, che eseguita con
un controllo (\texttt{\small 33}) sul valore della variabile \var{debugging}
impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
-preimpostato, non accade nulla. altrimenti (\texttt{\small 33}) l'indirizzo
+preimpostato, non accade nulla, altrimenti (\texttt{\small 33}) l'indirizzo
ricevuto da \var{accept} viene convertito in una stringa che poi
(\texttt{\small 34--39}) viene opportunamente stampata o sullo schermo o nei
log.
un controllo in caso di errore; il codice della nuova versione è mostrato in
fig.~\ref{fig:TCP_ServEcho_second}.
-\begin{figure}[!htbp]
- \footnotesize \centering
- \begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/ServEcho_second.c}
- \end{minipage}
- \normalsize
- \caption{Codice della seconda versione della funzione \code{ServEcho} per la
- gestione del servizio \textit{echo}.}
- \label{fig:TCP_ServEcho_second}
-\end{figure}
-
-Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
+ Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
ritorno di \func{read} per rilevare un eventuale errore, in modo da stampare
(\texttt{\small 8}) un messaggio di errore e ritornare (\texttt{\small 9})
Inoltre qualora sia stata attivata la funzionalità di debug (avvalorando
\var{debugging} tramite l'apposita opzione \texttt{-d}) si provvederà a
-stampare (tenendo conto della modalità di invocazione del server, se
-interattiva o in forma di demone) il numero di byte e la stringa letta dal
-client (\texttt{\small 16--24}).
+stampare (\texttt{\small 16--24}) il numero di byte e la stringa letta dal
+client, tenendo conto della modalità di invocazione del server, se interattiva
+o in forma di demone.
\section{I vari scenari critici}
accennato in sez.~\ref{sec:TCP_func_accept} la funzione \func{accept} riporta
tutti gli eventuali errori di rete pendenti su una connessione sul
\textit{connected socket}. Di norma questo non è un problema, in quanto non
-appena completata la connessione, \func{accept} ritorna e l'errore sarà
-rilevato in seguito, dal processo che gestisce la connessione, alla prima
+appena completata la connessione, \func{accept} ritorna, e l'errore sarà
+rilevato in seguito dal processo che gestisce la connessione, alla prima
chiamata di una funzione che opera sul socket.
È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
connessione viene stabilita, ma subito dopo si ha una condizione di errore che
la chiude prima che essa sia stata accettata dal programma.
-Questo significa che, oltre alla interruzione da parte di un segnale, che
+Questo significa che oltre alla interruzione da parte di un segnale, che
abbiamo trattato in sez.~\ref{sec:TCP_child_hand} nel caso particolare di
\signal{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
-\func{accept}, che come nel caso precedente, necessitano semplicemente la
-ripetizione della chiamata senza che si debba uscire dal programma. In questo
-caso anche la versione modificata del nostro server non sarebbe adatta, in
-quanto uno di questi errori causerebbe la terminazione dello stesso. In Linux
-i possibili errori di rete non fatali, riportati sul socket connesso al
-ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
+\func{accept}; questi, come nel caso precedente, necessitano semplicemente la
+ripetizione della chiamata senza uscire dal programma. In questo caso anche la
+versione modificata del nostro server non sarebbe adatta, in quanto uno di
+questi errori causerebbe la terminazione dello stesso. In Linux i possibili
+errori di rete non fatali, riportati sul socket connesso al ritorno di
+\func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
\errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
\errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
connessione usando il programma client. In tal caso infatti, alla terminazione
del client, il socket associato alla connessione viene semplicemente chiuso,
attraverso la sequenza vista in sez.~\ref{sec:TCP_conn_term}, per cui la
-\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
-al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
-modifichi il client per fargli gestire l'invio di un segmento di RST alla
-chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
-sez.~\ref{sec:sock_options_main}), non si ha nessun errore al ritorno di
-\func{accept}, quanto un errore di \errcode{ECONNRESET} al primo tentativo di
-accesso al socket.
+\func{accept} ritornerà senza errori, e si avrà semplicemente un
+\textit{end-of-file} al primo accesso al socket. Nel caso di Linux inoltre,
+anche qualora si modifichi il client per fargli gestire l'invio di un segmento
+RST alla chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
+sez.~\ref{sec:sock_options_main}), non si ha comunque nessun errore al ritorno
+di \func{accept}, quanto un errore di \errcode{ECONNRESET} al primo tentativo
+di accesso al socket.
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
Lanciando il comando prima di ripetere la sessione di lavoro mostrata
nell'esempio precedente potremo allora catturare tutti pacchetti scambiati fra
-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
+il client ed il server; i risultati (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{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
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}.
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
\end{figure}
Come si può vedere in questo caso si controlla il valore di ritorno di tutte
-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
+le funzioni, ed inoltre si verifica la presenza di un eventuale
+\textit{end-of-file} in caso di lettura. Con questa modifica il nostro client
+\cmd{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{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
nulla fintanto che è bloccato nella lettura del terminale fatta con
\func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
-fare con la necessità di lavorare con più descrittori, nel qual caso diventa
-si pone la questione di come fare a non restare bloccati su un socket quando
-altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
+fare con la necessità di lavorare con più descrittori, nel qual caso si pone
+la questione di come fare a non restare bloccati su un socket quando altri
+potrebbero essere liberi. Vedremo come affrontare questa problematica in
sez.~\ref{sec:TCP_sock_multiplexing}.
della connessione, un altro caso è ad esempio quello in cui si ha un crollo
della rete, cosa che potremo simulare facilmente staccando il cavo di rete.
Un'altra condizione è quella di un blocco della macchina completo della su cui
-gira il server che deve essere riavviata, cosa che potremo simulare sia
-premendo il bottone di reset,\footnote{un normale shutdown non va bene; in tal
- caso infatti il sistema provvede a terminare tutti i processi, per cui la
- situazione sarebbe sostanzialmente identica alla precedente.} che, in
-maniera più gentile, riavviando la macchina dopo aver interrotto la
-connessione di rete.
+gira il server che deve essere riavviata, cosa che potremo simulare eseguendo
+un reset fisico,\footnote{un normale shutdown non va bene; in tal caso infatti
+ il sistema provvede a terminare tutti i processi, per cui la situazione
+ sarebbe sostanzialmente identica alla precedente.} che, in maniera più
+gentile, riavviando la macchina dopo aver interrotto la connessione di rete.
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
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
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
\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
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}.
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
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
multiplexing nella nostra analisi degli errori in
sez.~\ref{sec:TCP_conn_early_abort}, quando il nostro client non era in grado
di rendersi conto di errori sulla connessione essendo impegnato nella attesa
-di dati in ingresso dallo standard input.
+di dati in ingresso dallo \textit{standard input}.
In questo caso il problema è quello di dover tenere sotto controllo due
-diversi file descriptor, lo standard input, da cui viene letto il testo che
-vogliamo inviare al server, e il socket connesso con il server su cui detto
-testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
-dell'I/O multiplexing consente di tenere sotto controllo entrambi, senza
-restare bloccati.
+diversi file descriptor, lo \textit{standard input}, da cui viene letto il
+testo che vogliamo inviare al server, e il socket connesso con il server su
+cui detto testo sarà scritto e dal quale poi si vorrà ricevere la
+risposta. L'uso dell'I/O multiplexing consente di tenere sotto controllo
+entrambi, senza restare bloccati.
Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
-standard input in caso di errori sulla connessione o chiusura della stessa da
-parte del server. Entrambi questi casi possono essere rilevati usando
-\func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select}, mettendo
-sotto osservazione i file descriptor per la condizione di essere pronti in
-lettura: sia infatti che si ricevano dati, che la connessione sia chiusa
-regolarmente (con la ricezione di un segmento FIN) che si riceva una
+\textit{standard input} in caso di errori sulla connessione o chiusura della
+stessa da parte del server. Entrambi questi casi possono essere rilevati
+usando \func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select},
+mettendo sotto osservazione i file descriptor per la condizione di essere
+pronti in lettura: sia infatti che si ricevano dati, che la connessione sia
+chiusa regolarmente (con la ricezione di un segmento FIN) che si riceva una
condizione di errore (con un segmento RST) il socket connesso sarà pronto in
lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
nostri scopi).
La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
(\texttt{\small 11--12}) il \textit{file descriptor set}, impostando i valori
-per il file descriptor associato al socket \var{socket} e per lo standard
-input (il cui valore si recupera con la funzione \func{fileno}). Questo è
-necessario in quanto la successiva (\texttt{\small 13}) chiamata a
-\func{select} comporta una modifica dei due bit relativi, che quindi devono
-essere reimpostati all'inizio di ogni ciclo.
+per il file descriptor associato al socket \var{socket} e per lo
+\textit{standard input} (il cui valore si recupera con la funzione
+\func{fileno}). Questo è necessario in quanto la successiva (\texttt{\small
+ 13}) chiamata a \func{select} comporta una modifica dei due bit relativi,
+che quindi devono essere reimpostati all'inizio di ogni ciclo.
Si noti come la chiamata a \func{select} venga eseguita usando come primo
argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
Al ritorno di \func{select} si provvede a controllare quale dei due file
descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
-con il file descriptor associato allo standard input. In caso di attività
-(quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
-(\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati presenti;
-se non ve ne sono (e la funzione restituisce pertanto un puntatore nullo) si
-ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
-chiuso lo standard input e quindi concluso l'utilizzo del client; altrimenti
-(\texttt{\small 18--22}) si scrivono i dati appena letti sul socket,
-prevedendo una uscita immediata in caso di errore di scrittura.
-
-Controllato lo standard input si passa a controllare (\texttt{\small 25--40})
-il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
-una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
-(\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
-immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
-il server ha chiuso la connessione, e di nuovo si esce con stampando prima un
-messaggio di avviso, altrimenti (\texttt{\small 35--39}) si effettua la
-terminazione della stringa e la si stampa a sullo standard output (uscendo in
-caso di errore), per ripetere il ciclo da capo.
+con il file descriptor associato allo \textit{standard input}. In caso di
+attività (quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si
+esegue (\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati
+presenti; se non ve ne sono (e la funzione restituisce pertanto un puntatore
+nullo) si ritorna immediatamente (\texttt{\small 16}) dato che questo
+significa che si è chiuso lo \textit{standard input} e quindi concluso l'utilizzo del
+client; altrimenti (\texttt{\small 18--22}) si scrivono i dati appena letti
+sul socket, prevedendo una uscita immediata in caso di errore di scrittura.
+
+Controllato lo \textit{standard input} si passa a controllare (\texttt{\small
+ 25--40}) il socket connesso, in caso di attività (\texttt{\small 26}) si
+esegue subito una \func{read} di cui si controlla il valore di ritorno; se
+questo è negativo (\texttt{\small 27--30}) si è avuto un errore e pertanto si
+esce immediatamente segnalandolo, se è nullo (\texttt{\small 31--34})
+significa che il server ha chiuso la connessione, e di nuovo si esce con
+stampando prima un messaggio di avviso, altrimenti (\texttt{\small 35--39}) si
+effettua la terminazione della stringa e la si stampa a sullo \textit{standard
+ output} (uscendo in caso di errore), per ripetere il ciclo da capo.
Con questo meccanismo il programma invece di essere bloccato in lettura sullo
-standard input resta bloccato sulla \func{select}, che ritorna soltanto quando
-viene rilevata attività su uno dei due file descriptor posti sotto controllo.
-Questo di norma avviene solo quando si è scritto qualcosa sullo standard
-input, o quando si riceve dal socket la risposta a quanto si era appena
-scritto. Ma adesso il client diventa capace di accorgersi immediatamente della
-terminazione del server; in tal caso infatti il server chiuderà il socket
-connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
-illustrato in sez.~\ref{sec:TCP_sock_select}) segnalando una condizione di end
-of file, per cui il nostro client potrà uscire immediatamente.
+\textit{standard input} resta bloccato sulla \func{select}, che ritorna
+soltanto quando viene rilevata attività su uno dei due file descriptor posti
+sotto controllo. Questo di norma avviene solo quando si è scritto qualcosa
+sullo \textit{standard input}, o quando si riceve dal socket la risposta a quanto si
+era appena scritto. Ma adesso il client diventa capace di accorgersi
+immediatamente della terminazione del server; in tal caso infatti il server
+chiuderà il socket connesso, ed alla ricezione del FIN la funzione
+\func{select} ritornerà (come illustrato in sez.~\ref{sec:TCP_sock_select})
+segnalando una condizione di end of file, per cui il nostro client potrà
+uscire immediatamente.
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.
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
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.
rendere finalmente completo il nostro esempio sul servizio \textit{echo}. Il
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}%$
+usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo
+\textit{standard input} e \textit{standard output}. Così se eseguiamo:
+\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
-comunicazione via rete; quando redirigiamo lo standard input il nostro client
-inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
-dimensione massima pari a \texttt{MAXLINE} per poi scriverlo, alla massima
-velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
-una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
-vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
-di processo, questo tempo è quello impiegato nella trasmissione via rete, che
-viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time~(RTT)}
-\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
-\cmd{ping}.
+comunicazione via rete; quando redirigiamo lo \textit{standard input} il
+nostro client inizierà a leggere il contenuto del file \texttt{../fileadv.tex}
+a blocchi di dimensione massima pari a \texttt{MAXLINE} per poi scriverlo,
+alla massima velocità consentitagli dalla rete, sul socket. Dato che la
+connessione è con una macchina remota occorre un certo tempo perché i
+pacchetti vi arrivino, vengano processati, e poi tornino
+indietro. Considerando trascurabile il tempo di processo, questo tempo è
+quello impiegato nella trasmissione via rete, che viene detto RTT (dalla
+denominazione inglese \itindex{Round~Trip~Time~(RTT)} \textit{Round Trip
+ Time}) ed è quello che viene stimato con l'uso del comando \cmd{ping}.
A questo punto, se torniamo al codice mostrato in
fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
subordinato ad un valore nullo di \var{eof} l'impostazione del file descriptor
-set per l'osservazione dello standard input. Se infatti il valore di \var{eof}
-è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
-pertanto inutile continuare a tenere sotto controllo lo standard input nella
-successiva (\texttt{\small 16}) chiamata a \func{select}.
+set per l'osservazione dello \textit{standard input}. Se infatti il valore di
+\var{eof} è non nullo significa che si è già raggiunta la fine del file in
+ingresso ed è pertanto inutile continuare a tenere sotto controllo lo
+\textit{standard input} nella successiva (\texttt{\small 16}) chiamata a
+\func{select}.
Le maggiori modifiche rispetto alla precedente versione sono invece nella
gestione (\texttt{\small 18--22}) del caso in cui la lettura con \func{fgets}
prima (\texttt{\small 19}) si imposta opportunamente \var{eof} ad un valore
non nullo, dopo di che (\texttt{\small 20}) si effettua la chiusura del lato
in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si
-usa la macro \macro{FD\_CLR} per togliere lo standard input dal \textit{file
- descriptor set}.
+usa la macro \macro{FD\_CLR} per togliere lo \textit{standard input} dal
+\textit{file descriptor set}.
In questo modo anche se la lettura del file in ingresso è conclusa, la
funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
ad eseguirlo ripetendo la chiamata a \func{select} per tenere sotto controllo
soltanto il socket connesso, dal quale possono arrivare altri dati, che
saranno letti (\texttt{\small 31}), ed opportunamente trascritti
-(\texttt{\small 44--48}) sullo standard output.
+(\texttt{\small 44--48}) sullo \textit{standard output}.
Il ritorno della funzione, e la conseguente terminazione normale del client,
viene invece adesso gestito all'interno (\texttt{\small 30--49}) della lettura
\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
-modalità interattiva, lo spreco di tre strutture (quelle relative a standard
-input, output ed error) che non vengono mai utilizzate in quanto la prima è
-sempre quella relativa al socket in ascolto.
+modalità interattiva, lo spreco di tre strutture (quelle relative a
+\textit{standard input}, \textit{standard output} e \textit{standard error})
+che non vengono mai utilizzate in quanto la prima è sempre quella relativa al
+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
projects / gapil.git / blobdiff