\label{cha:network}
In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
-come prerequisiti per capire la programmazione di rete, partiremo con due
-semplici esempi per poi passare ad un esame a grandi linee dei protocolli di
-rete e di come questi sono organizzati e interagiscono.
+come prerequisiti per capire la programmazione di rete, per evitare un
+capitolo puramente teorico partiremo con due semplici esempi per poi passare
+ad un esame a grandi linee dei protocolli di rete e di come questi sono
+organizzati e interagiscono.
In particolare, avendo assunto l'ottica di un'introduzione mirata alla
-programmazione, ci concentreremo sul protocollo più diffuso, TCP/IP, che è
-quello che sta alla base di internet, ed in particolare prenderemo in esame in
-questa introduzione i concetti più importanti da conoscere ai fini della
-programmazione.
+programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
+quello che sta alla base di internet, con un'ottica improntata a sottolineare
+i concetti più importanti da conoscere ai fini della programmazione.
\section{Il modello client-server}
\label{sec:net_cliserv}
come il sistema a finestre.
Normalmente si dividono i server in due categorie principali, e vengono detti
-\textit{concorrenti} o \textit{iterativi}, sulla base del loro comportamento.
+\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
-Un server iterativo risponde alla richiesta inviando i dati e resta occupato
-(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
-richiesta. Una volta completata la richiesta il server diventa di nuovo
+Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
+occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
+la richiesta. Una volta completata la richiesta il server diventa di nuovo
disponibile.
-Un server concorrente al momento di trattare la richiesta crea un processo
-figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
-ulteriori richieste. In questo modo più richieste possono essere soddisfatte
-contemporaneamente; una volta che il processo figlio ha concluso il suo lavoro
-viene terminato, mentre il server originale resta sempre attivo.
+Un \textsl{server concorrente} al momento di trattare la richiesta crea un
+processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
+attesa di ulteriori richieste. In questo modo più richieste possono essere
+soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
+il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
\subsection{Un primo esempio di client}
dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
tutta la parte relativa al trattamento degli argomenti passati dalla linea di
comando (effettuata con le apposite routines illustrate in
-\ref{cha:parameter_options}).
+\capref{cha:parameter_options}).
Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
(\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale
anche la corrispondenza fra i rispettivi livelli (che comunque è
approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
operativo rispetto alla divisione fra user space e kernel space spiegata in
-\ref{sec:intro_unix_struct}.
+\secref{sec:intro_unix_struct}.
\begin{table}[htb]
\centering
\begin{description}
\item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
genere questi vengono realizzati secondo il modello Client-Server (vedi
- \ref{sec:net_cliserv}.
+ \secref{sec:net_cliserv}.
\item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
terminali su cui girano gli applicativi, regola il flusso delle
informazioni, e può fornire un trasporto affidabile, cioè con recupero
da ICMPv6.
\item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
protocollo usato per il \textit{multicasting} (vedi
- \ref{sec:xxx_multicast}), che è opzionale in IPv4.
+ \secref{sec:xxx_multicast}), che è opzionale in IPv4.
\item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
internet). È usato in reti di tipo broadcast come ethernet, token ring o
\end{itemize}
Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
-protocollo IP sono forniti nell'appendice \ref{cha:ip_protocol}.
+protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
\subsection{UDP: User Datagram Protocol)}
\label{sec:net_udp}
UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
-contenuta dell'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 \ref{sec:appA_udp}), 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.
+contenuta dell'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 \secref{sec:appA_udp}), 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
effettuato per entrambe le direzioni di comunicazione.
Una descrizione più accurata del protocollo è fornita in appendice
-\ref{cha:tcp_protocol}.
+\capref{cha:tcp_protocol}.
\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
\label{sec:net_lim_dim}
\item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
apposito nell'header di IP che è lungo 16 bit (vedi
- \ref{sec:appA_ipv4head}).
+ \secref{sec:appA_ipv4head}).
\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
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
un pacchetto usando la \textit{jumbo payload option}.
-\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che è
- imposta dalle modalità di funzionamento dall'hardware. Il più comune è
- quello dell'ethernet che è pari a 1500 bytes. La MTU più piccola fra due
- stazioni viene in genere chiamata \textit{path MTU}, e al giorno d'oggi è
- normalmente data da ethernet; si tenga conto che non è affatto detto che sia
- la stessa in entrambe le direzioni, anche perchè l'instradamento può essere
- diverso.
+\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che
+ dipende dal protocollo specifico usato al livello di link. Il più comune è
+ quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili
+ sono riportati in \ntab.
\end{itemize}
+\begin{table}[!htb]
+ \centering
+ \begin{tabular}[c]{|l|c|}
+ \textbf{Rete} & \textbf{MTU} \\
+ \hline
+ Hyperlink & 65535 \\
+ Token Ring IBM (16 Mbit/sec) & 17914 \\
+ Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
+ FDDI & 4532 \\
+ Ethernet & 1500 \\
+ X.25 & 576 \\
+ \end{tabular}
+ \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di
+ reti diverse.}
+ \label{tab:net_mtu_values}
+\end{table}
+
Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
dimensioni eccedono la MTU viene eseguita la cosiddetta
-\textit{frammentazione} (sia da IPv4 che da IPv6, anche se i pacchetti
-frammentati sono gestiti con modalità diverse\footnote{il primo usa un flag
- nell'header, il secondo una opportuna opzione, si veda
- \ref{cha:ip_protcol}}), i pacchetti cioè vengono spezzati in blocchi più
-piccoli che possono essere trasmessi attraverso l'interfaccia.
+\textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
+IPv6, anche se i pacchetti frammentati sono gestiti con modalità
+diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna
+ opzione, si veda \secref{cha:ip_protcol}}), in blocchi più piccoli che
+possono essere trasmessi attraverso l'interfaccia.
+
+La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
+ MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
+inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
+conto che non è affatto detto che la \textit{path MTU} sia la stessa in
+entrambe le direzioni, perchè l'instradamento può essere diverso nei due
+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
destinazione.
Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
-pacchetto non deve essere frammentato; un router che riceva uno di questi
-pacchetti le cui dimensioni eccedono quelle dell'MTU della rete di
-destinazione genererà un messaggio di errore ICMPv4 di tipo
-\textit{destination unreachable, fragentation needed but DF bit set}.
+pacchetto non deve essere frammentato; un router che riceva un pacchetto le
+cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
+messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
+ fragentation needed but DF bit set}.
Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
un messaggio di errore ICMPv6 di tipo \textit{paket too big}.
Dato che il meccanismo di frammentazione e riassemblaggio comporta
-inefficienza è opportuno che la trasmissione di grosse quantità di dati sia
-gestita in maniera oculata, TCP provvede un meccanismo automatico di
-
-In genere il flag DF di IPv4 (e il comportamento normale di IPv6) vengono
-utilizzati per il processo della \textit{path MTU discover} (vedi RFC1191 per
-IPv4 e RFC1981 per IPv6) in cui inviando delle opportune serie di pacchetti si
-trova il \textit{path MTU}; TCP usa questo meccanismo che è opzionale per
-IPv4, ma necessario (dato che i pacchetti verrebbero bloccati) per IPv6.
+inefficienza normalmente viene utilizzato il procedimento della \textit{path
+ MTU discover} (vedi RFC1191 per IPv4 e RFC1981 per IPv6) che permette dui
+trovare 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 l'RFC1191
+per IPv4 e l'RFC1981 per IPv6) fintanto che non si hanno più errori.
+
+Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
+opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
+potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
+conoscere il \textit{path MTU}.
+
Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
all'altro capo la dimensione massima del segmento di dati
projects / gapil.git / blobdiff