X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=613aea4de6e9afa31dfdbee8925dc179d4b01bc8;hp=8756e05e4331e6a5d43db9db9810fe6dfe431c10;hb=6c2be511ebf59148d64ae0da7f44e21b2bd92e73;hpb=c46df2fabf1fd8946892f9adf0771831a5c0f796 diff --git a/tcpsock.tex b/tcpsock.tex index 8756e05..613aea4 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -1,6 +1,6 @@ %% tcpsock.tex %% -%% Copyright (C) 2000-2013 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -144,29 +144,28 @@ connessione. Normalmente vengono usate le seguenti opzioni: sez.~\ref{sec:sock_tcp_udp_options}). \item \textit{window scale option}, il protocollo TCP implementa il controllo - di flusso attraverso una \itindex{advertised~window} \textit{advertised - window} (la ``\textsl{finestra annunciata}'', vedi - sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun capo della - comunicazione dichiara quanto spazio disponibile ha in memoria per i dati. - Questo è un numero a 16 bit dell'header, che così può indicare un massimo di - 65535 byte;\footnote{in Linux il massimo è 32767 per evitare problemi con - alcune implementazioni che usano l'aritmetica con segno per implementare - lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità - (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel cammino dei - pacchetti (come i satelliti) richiedono una finestra più grande per poter - ottenere il massimo dalla trasmissione. Per questo esiste questa opzione che - indica un fattore di scala da applicare al valore della - \itindex{advertised~window} finestra annunciata\footnote{essendo una nuova - opzione per garantire la compatibilità con delle vecchie implementazioni - del protocollo la procedura che la attiva prevede come negoziazione che - l'altro capo della connessione riconosca esplicitamente l'opzione - inserendola anche lui nel suo SYN di risposta dell'apertura della - connessione.} per la connessione corrente (espresso come numero di bit cui - spostare a sinistra il valore della finestra annunciata inserito nel - pacchetto). Con Linux è possibile indicare al kernel di far negoziare il - fattore di scala in fase di creazione di una connessione tramite la - \textit{sysctl} \itindex{TCP~window~scaling} \texttt{tcp\_window\_scaling} - (vedi sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa + di flusso attraverso una \textit{advertised window} (la ``\textsl{finestra + annunciata}'', vedi sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun + capo della comunicazione dichiara quanto spazio disponibile ha in memoria + per i dati. Questo è un numero a 16 bit dell'header, che così può indicare + un massimo di 65535 byte;\footnote{in Linux il massimo è 32767 per evitare + problemi con alcune implementazioni che usano l'aritmetica con segno per + implementare lo stack TCP.} ma alcuni tipi di connessione come quelle ad + alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel + cammino dei pacchetti (come i satelliti) richiedono una finestra più grande + per poter ottenere il massimo dalla trasmissione. Per questo esiste questa + opzione che indica un fattore di scala da applicare al valore della finestra + annunciata\footnote{essendo una nuova opzione per garantire la compatibilità + con delle vecchie implementazioni del protocollo la procedura che la + attiva prevede come negoziazione che l'altro capo della connessione + riconosca esplicitamente l'opzione inserendola anche lui nel suo SYN di + risposta dell'apertura della connessione.} per la connessione corrente + (espresso come numero di bit cui spostare a sinistra il valore della + finestra annunciata inserito nel pacchetto). Con Linux è possibile indicare + al kernel di far negoziare il fattore di scala in fase di creazione di una + connessione tramite la \textit{sysctl} \itindex{TCP~window~scaling} + \texttt{tcp\_window\_scaling} (vedi + sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa funzionalità è comunque necessario ampliare le dimensioni dei buffer di ricezione e spedizione, cosa che può essere fatta sia a livello di sistema con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl}) @@ -1299,7 +1298,7 @@ Quando ci si trova ad affrontare questo comportamento tutto quello che si deve fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non sono disponibili: è lo stesso comportamento che si può avere scrivendo più di -\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in +\const{PIPE\_BUF} byte in una \textit{pipe} (si riveda quanto detto in sez.~\ref{sec:ipc_pipes}). Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono @@ -1325,9 +1324,10 @@ disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo fino all'esaurimento del numero di byte richiesti, in caso di errore viene -controllato se questo è \errcode{EINTR} (cioè un'interruzione della system -call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti -l'errore viene ritornato al programma chiamante, interrompendo il ciclo. +controllato se questo è \errcode{EINTR} (cioè un'interruzione della +\textit{system call} dovuta ad un segnale), nel qual caso l'accesso viene +ripetuto, altrimenti l'errore viene ritornato al programma chiamante, +interrompendo il ciclo. Nel caso della lettura, se il numero di byte letti è zero, significa che si è arrivati alla fine del file (per i socket questo significa in genere che @@ -1385,7 +1385,7 @@ il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è inizializzare tutto a zero, per poi inserire il tipo di indirizzo (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima la funzione \func{htons} per convertire il formato dell'intero usato dal -computer a quello usato nella rete, infine \texttt{\small 23--27} si può +computer a quello usato nella rete, infine (\texttt{\small 23--27}) si può utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di comando. @@ -2062,11 +2062,11 @@ all'esempio illustrato in fig.~\ref{fig:TCP_echo_server_first_code}. In questo modo però si introduce un altro problema. Si ricordi infatti che, come spiegato in sez.~\ref{sec:sig_gen_beha}, quando un programma si trova in -stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene -interrotta alla ricezione di un segnale. Per questo motivo, alla fine -dell'esecuzione del gestore del segnale, se questo ritorna, il programma -riprenderà l'esecuzione ritornando dalla system call interrotta con un errore -di \errcode{EINTR}. +stato di \texttt{sleep} durante l'esecuzione di una \textit{system call}, +questa viene interrotta alla ricezione di un segnale. Per questo motivo, alla +fine dell'esecuzione del gestore del segnale, se questo ritorna, il programma +riprenderà l'esecuzione ritornando dalla \textit{system call} interrotta con +un errore di \errcode{EINTR}. Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il client, il processo figlio che gestisce la connessione terminerà, ed il padre, @@ -2083,13 +2083,13 @@ accept error: Interrupted system call \end{verbatim}%# Come accennato in sez.~\ref{sec:sig_gen_beha} le conseguenze di questo -comportamento delle system call possono essere superate in due modi diversi, -il più semplice è quello di modificare il codice di \func{Signal} per -richiedere il riavvio automatico delle system call interrotte secondo la -semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction}; -rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora la -nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme - alle altre funzioni riguardanti la gestione dei segnali, nel file +comportamento delle \textit{system call} possono essere superate in due modi +diversi, il più semplice è quello di modificare il codice di \func{Signal} per +richiedere il riavvio automatico delle \textit{system call} interrotte secondo +la semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction}; +rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora +la nuova funzione \func{SignalRestart}\footnote{anche questa è definita, + insieme alle altre funzioni riguardanti la gestione dei segnali, nel file \file{SigHand.c}, il cui contento completo può essere trovato negli esempi allegati.} come mostrato in fig.~\ref{fig:sig_SignalRestart_code}, ed installeremo il gestore usando quest'ultima. @@ -2101,30 +2101,30 @@ installeremo il gestore usando quest'ultima. \end{minipage} \normalsize \caption{La funzione \func{SignalRestart}, che installa un gestore di - segnali in semantica BSD per il riavvio automatico delle system call - interrotte.} + segnali in semantica BSD per il riavvio automatico delle \textit{system + call} interrotte.} \label{fig:sig_SignalRestart_code} \end{figure} Come si può notare questa funzione è identica alla precedente \func{Signal}, -illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece di -inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si +illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece +di inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa funzione al posto di \func{Signal} nel server non è necessaria nessuna altra -modifica: le system call interrotte saranno automaticamente riavviate, e -l'errore \errcode{EINTR} non si manifesterà più. +modifica: le \textit{system call} interrotte saranno automaticamente +riavviate, e l'errore \errcode{EINTR} non si manifesterà più. La seconda soluzione è più invasiva e richiede di controllare tutte le volte -l'errore restituito dalle varie system call, ripetendo la chiamata qualora -questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio -della portabilità, infatti lo standard POSIX dice che la funzionalità di -riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è -opzionale, per cui non è detto che essa sia disponibile su qualunque sistema. -Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior - parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri - non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel - caso di Linux viene sempre fatta.} anche quando questa è presente, non è -detto possa essere usata con \func{accept}. +l'errore restituito dalle varie \textit{system call}, ripetendo la chiamata +qualora questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il +pregio della portabilità, infatti lo standard POSIX dice che la funzionalità +di riavvio automatico delle \textit{system call}, fornita da +\const{SA\_RESTART}, è opzionale, per cui non è detto che essa sia disponibile +su qualunque sistema. Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} + accenna che la maggior parte degli Unix derivati da BSD non fanno ripartire + \func{select}; altri non riavviano neanche \func{accept} e \func{recvfrom}, + 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 @@ -2160,7 +2160,7 @@ programma. \normalsize \caption{La sezione nel codice della seconda versione del server per il servizio \textit{echo} modificata per tener conto dell'interruzione - delle system call.} + delle \textit{system call}.} \label{fig:TCP_echo_server_code_second} \end{figure} @@ -2182,12 +2182,12 @@ eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile numero di secondi da aspettare (il valore preimpostato è nullo). Si è potuto lasciare inalterata tutta la sezione di creazione del socket -perché nel server l'unica chiamata ad una system call lenta, che può essere -interrotta dall'arrivo di \signal{SIGCHLD}, è quella ad \func{accept}, che è -l'unica funzione che può mettere il processo padre in stato di sleep nel +perché nel server l'unica chiamata ad una \textit{system call} lenta, che può +essere interrotta dall'arrivo di \signal{SIGCHLD}, è quella ad \func{accept}, +che è l'unica funzione che può mettere il processo padre in stato di sleep nel periodo in cui un figlio può terminare; si noti infatti come le altre -\index{system~call~lente} \textit{slow system call}\footnote{si ricordi la - distinzione fatta in sez.~\ref{sec:sig_gen_beha}.} o sono chiamate prima di +\index{system~call~lente} \textit{system call} lente (si ricordi la +distinzione fatta in sez.~\ref{sec:sig_gen_beha}) o sono chiamate prima di entrare nel ciclo principale, quando ancora non esistono processi figli, o sono chiamate dai figli stessi e non risentono di \signal{SIGCHLD}. @@ -2399,13 +2399,13 @@ si aveva il SYN flag attivo. Si noti come a partire dal secondo pacchetto sia sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene espresso in forma relativa per maggiore compattezza. Il campo \texttt{win} in -ogni riga indica la \itindex{advertised~window} \textit{advertised window} di -cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare -dall'output del comando come venga appunto realizzata la sequenza di pacchetti -descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un -primo pacchetto con il SYN che inizia la connessione, a cui il server risponde -dando il ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui -il client risponde con un il terzo pacchetto di ricevuto. +ogni riga indica la \textit{advertised window} di cui parlavamo in +sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare dall'output del comando +come venga appunto realizzata la sequenza di pacchetti descritta in +sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un primo pacchetto +con il SYN che inizia la connessione, a cui il server risponde dando il +ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui il client +risponde con un il terzo pacchetto di ricevuto. Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe del \itindex{three~way~handshake} \textit{three way handshake} non avremo @@ -2467,15 +2467,16 @@ avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket è una operazione lecita, per cui la nostra scrittura avrà comunque successo (come si può constatare lanciando usando \cmd{strace}\footnote{il comando \cmd{strace} è un comando di debug molto utile che prende come argomento un - altro comando e ne stampa a video tutte le invocazioni di una system call, - coi relativi argomenti e valori di ritorno, per cui usandolo in questo - contesto potremo verificare che effettivamente la \func{write} ha scritto la - riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro -programma non ha a questo punto alcun modo di sapere che dall'altra parte non -c'è più nessuno processo in grado di leggere quanto scriverà. Questo sarà -chiaro solo dopo il tentativo di scrittura, e la ricezione del segmento RST di -risposta che indica che dall'altra parte non si è semplicemente chiuso un capo -del socket, ma è completamente terminato il programma. + altro comando e ne stampa a video tutte le invocazioni di una \textit{system + call}, coi relativi argomenti e valori di ritorno, per cui usandolo in + questo contesto potremo verificare che effettivamente la \func{write} ha + scritto la riga, che in effetti è stata pure trasmessa via rete.}), in +quanto il nostro programma non ha a questo punto alcun modo di sapere che +dall'altra parte non c'è più nessuno processo in grado di leggere quanto +scriverà. Questo sarà chiaro solo dopo il tentativo di scrittura, e la +ricezione del segmento RST di risposta che indica che dall'altra parte non si +è semplicemente chiuso un capo del socket, ma è completamente terminato il +programma. Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che questo è stato chiuso avremo che, come spiegato in @@ -2490,12 +2491,12 @@ Per capire come questa avvenga comunque, non avendo inserito nel codice nessun controllo di errore, occorre ricordare che, a parte la bidirezionalità del flusso dei dati, dal punto di vista del funzionamento nei confronti delle funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle -pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che -tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è -aperto il lettura il processo riceve un segnale di \signal{SIGPIPE}, e questo è -esattamente quello che avviene in questo caso, e siccome non abbiamo un -gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella -di terminare il processo. +\textit{pipe}. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, +sappiamo che tutte le volte che si cerca di scrivere su una \textit{pipe} il +cui altro capo non è aperto il lettura il processo riceve un segnale di +\signal{SIGPIPE}, e questo è esattamente quello che avviene in questo caso, e +siccome non abbiamo un gestore per questo segnale, viene eseguita l'azione +preimpostata, che è quella di terminare il processo. Per gestire in maniera più corretta questo tipo di evento dovremo allora modificare il nostro client perché sia in grado di trattare le varie tipologie @@ -2771,13 +2772,14 @@ sappiamo che la funzione ritorna quando uno o più dei file descriptor messi sotto controllo è pronto per la relativa operazione. In quell'occasione non abbiamo però definito cosa si intende per pronto, -infatti per dei normali file, o anche per delle pipe, la condizione di essere -pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso -dei socket, visto che possono intervenire tutte una serie di possibili -condizioni di errore dovute alla rete. Occorre allora specificare chiaramente -quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}'' -quando viene passato come membro di uno dei tre \itindex{file~descriptor~set} -\textit{file descriptor set} usati da \func{select}. +infatti per dei normali file, o anche per delle \textit{pipe}, la condizione +di essere pronti per la lettura o la scrittura è ovvia; invece lo è molto meno +nel caso dei socket, visto che possono intervenire tutte una serie di +possibili condizioni di errore dovute alla rete. Occorre allora specificare +chiaramente quali sono le condizioni per cui un socket risulta essere +``\textsl{pronto}'' quando viene passato come membro di uno dei tre +\itindex{file~descriptor~set} \textit{file descriptor set} usati da +\func{select}. Le condizioni che fanno si che la funzione \func{select} ritorni segnalando che un socket (che sarà riportato nel primo insieme di file descriptor) è