From b52f6b91fcc6e0bc4a1522462f61f5f62e684bfe Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Thu, 5 Oct 2006 13:17:53 +0000 Subject: [PATCH] Alcune correzioni, con dei riferimenti ad argomenti trattati secoli fa e che adeso risaltano fuori nella nuova sezione sulla gestione dei socket. --- network.tex | 47 +++++++++++++++++++++++------------------------ sockctrl.tex | 4 +++- tcpsock.tex | 18 ++++++++++++------ 3 files changed, 38 insertions(+), 31 deletions(-) diff --git a/network.tex b/network.tex index e5d7405..869907f 100644 --- a/network.tex +++ b/network.tex @@ -350,15 +350,15 @@ possa sopportare il carico in transito, ma permettere ai singoli nodi di scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano errati o non recapitabili. -L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello -di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua -natura inaffidabile, in quanto non è assicurata né una percentuale di -successo né un limite sui tempi di consegna dei pacchetti. +L'incarico di rendere il recapito pacchetti affidabile non spetta al livello +di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura +inaffidabile, in quanto non è assicurata né una percentuale di successo né un +limite sui tempi di consegna dei pacchetti. È il livello di trasporto che si deve occupare (qualora necessiti) del controllo del flusso dei dati e del recupero degli errori; questo è realizzato -dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto -al livello di trasporto o ai livelli superiori. +dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è +pertanto al livello di trasporto o ai livelli superiori. Infine le singole stazioni collegate alla rete non fungono soltanto da punti terminali di comunicazione, ma possono anche assumere il ruolo di @@ -423,7 +423,6 @@ relazioni reciproche e con alcune dalle principali applicazioni che li usano. I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i seguenti: - \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}} \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su @@ -575,17 +574,17 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}. \subsection{User Datagram Protocol (UDP)} \label{sec:net_udp} -UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è +UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in -sostanza esso è una semplice interfaccia a IP dal livello di trasporto. Quando -un'applicazione usa UDP essa scrive un pacchetto di dati (il cosiddetto -\textit{datagram} che da il nome al protocollo) su un socket, al pacchetto -viene aggiunto un header molto semplice (per una descrizione più accurata vedi -sez.~\ref{sec:udp_protocol}), e poi viene passato al livello superiore (IPv4 o -IPv6 che sia) che lo spedisce verso la destinazione. Dato che né IPv4 né IPv6 -garantiscono l'affidabilità niente assicura che il pacchetto arrivi a -destinazione, né che più pacchetti arrivino nello stesso ordine in cui sono -stati spediti. +sostanza esso è una semplice interfaccia al protocollo IP dal livello di +trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto di dati (il +cosiddetto \textit{datagram} che da il nome al protocollo) su un socket, al +pacchetto viene aggiunto un header molto semplice (per una descrizione più +accurata vedi sez.~\ref{sec:udp_protocol}), e poi viene passato al livello +superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione. Dato +che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il +pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso +ordine in cui sono stati spediti. Pertanto il problema principale che si affronta quando si usa UDP è la mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a @@ -702,7 +701,7 @@ alle eventuali implicazioni che possono avere, l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un campo apposito nell'header di IP che è lungo 16 bit (vedi fig.~\ref{fig:IP_ipv4_head}). -\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte, +\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte; il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di @@ -753,9 +752,9 @@ sensi, con diverse tipologie di rete coinvolte. Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non frammentano i pacchetti che ritrasmettono (anche se possono frammentare i -pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una -volta frammentati i pacchetti possono essere riassemblati solo alla -destinazione. +pacchetti che generano loro stessi), al contrario di quanto fanno i router +IPv4. In ogni caso una volta frammentati i pacchetti possono essere +riassemblati solo alla destinazione. Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il pacchetto non deve essere frammentato; un router che riceva un pacchetto le @@ -769,9 +768,9 @@ di tipo \textit{packet too big}. Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti comporta inefficienza, normalmente viene utilizzato un procedimento, detto \textit{path MTU discovery} che permette di determinare il \textit{path MTU} -fra due stazioni; per la realizzazione del procedimento si usa il flag DF di -IPv4 e il comportamento normale di IPv6 inviando delle opportune serie di -pacchetti (per i dettagli vedere +fra due stazioni; per la realizzazione del procedimento si usa il flag +\texttt{DF} di IPv4 e il comportamento normale di IPv6 inviando delle +opportune serie di pacchetti (per i dettagli vedere l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che non si hanno più errori. diff --git a/sockctrl.tex b/sockctrl.tex index c326766..ec5d9d7 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -4135,7 +4135,9 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti: possibile ottimizzare il server in modo che sia in grado di accettare connessioni più rapidamente. -\item[\texttt{tcp\_adv\_win\_scale}] +\item[\texttt{tcp\_adv\_win\_scale}] permette di impostare il valore di scala + usato nell'opzione \textit{window scale} del protocollo TCP (vedi + sez.~\ref{sec:TCP_TCP_opt}) \item[\texttt{tcp\_app\_win}] \item[\texttt{tcp\_bic\_low\_window}] diff --git a/tcpsock.tex b/tcpsock.tex index a82be2a..7261246 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -125,10 +125,14 @@ varr \subsection{Le opzioni TCP.} \label{sec:TCP_TCP_opt} -Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP -(le cosiddette \textit{TCP options}, che vengono inserite fra l'header e i -dati) che servono a comunicare all'altro capo una serie di parametri utili a -regolare la connessione. Normalmente vengono usate le seguenti opzioni: +Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP, +le cosiddette \textit{TCP options},\footnote{da non confondere con le opzioni + dei socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}, in + questo caso si tratta delle opzioni che vengono trasmesse come parte di un + pacchetto TCP, non delle funzioni che consentono di impostare i relativi + valori.} che vengono inserite fra l'header e i dati, e che servono a +comunicare all'altro capo una serie di parametri utili a regolare la +connessione. Normalmente vengono usate le seguenti opzioni: \begin{itemize} \item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size} @@ -136,7 +140,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: connessione annuncia all'altro il massimo ammontare di dati che vorrebbe accettare per ciascun segmento nella connessione corrente. È possibile leggere e scrivere questo valore attraverso l'opzione del socket - \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:TCP_TCP_opt}). + \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}}). \item \textit{window scale option}, il protocollo TCP implementa il controllo di flusso attraverso una \itindex{advertised~window} \textit{advertised @@ -158,7 +162,9 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: 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). + pacchetto). Con Linux è possibile impostare questo valore a livello di + sistema con una opportuna \textit{sysctl} (vedi + sez.~\ref{sec:sock_ipv4_sysctl}). \item \textit{timestamp option}, è anche questa una nuova opzione necessaria per le connessioni ad alta velocità per evitare possibili corruzioni di dati -- 2.30.2