\label{sec:net_cli_sample}
Per evitare di rendere l'esposizione dei concetti generali sulla rete
-puramente teorica iniziamo con il mostrare un semplice esempio di client TCP.
+puramente teorica iniziamo con il mostrare un esempio di un client TCP
+elementare. Scopo di questo esempio è fornire un primo approccio alla
+programmazione di rete, tutto questo sarà esaminato in dettaglio nei capitoli
+successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
+definizioni precise e dettagli di funzionamento che saranno trattati
+estensivamente più avanti.
+
In \nfig\ è riportata la sezione principale del codice del nostro client
elementare per il servizio \textit{daytime}, un servizio standard che
restituisce l'ora locale della macchina a cui si effettua la richesta.
-\begin{figure}[!htbp]
+
+\begin{figure}[!htb]
\footnotesize
\begin{lstlisting}{}
#include <sys/types.h> /* predefined types */
\label{fig:net_cli_code}
\end{figure}
-Scopo di questo esempio è fornire un primo approccio alla programmazione di
-rete, per questo motivo non ci dilungheremo nello spiegare il significato dei
-termini o il funzionamento delle varie funzioni utilizzate. Tutto questo sarà
-esaminato in dettaglio nel seguito, per cui qui ci limiteremo a citarli senza
-ulteriori dettagli.
-
Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che
comprende il trattamento delle opzioni e una funzione per stampare un
messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
struct sockaddr_in serv_add;
char buffer[MAXLINE];
time_t timeval;
-
...
-
/* create socket */
if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
perror("Socket creation error");
funzionamento è stato stato standardizzato dalla \textit{International
Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
-livelli, secondo la tabella in \ntab.
+livelli, secondo quanto riportato in \ntab.
\begin{table}[htb]
\centering
multimediali e/o ``real-time'')
\end{itemize}
-Per maggiori dettagli riguardo al protocollo si può consultare
-\ref{sec:appA_ip}.
+Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
+protocollo IP sono forniti nell'appendice \ref{cha:ip_protocol}.
\subsection{UDP: User Datagram Protocol)}
controllo di flusso e della gestione della sequenzialità dei dati viene
effettuato per entrambe le direzioni di comunicazione.
+Una descrizione più accurata del protocollo è fornita in appendice
+\ref{cha:tcp_protocol}.
+\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
+\label{sec:net_lim_dim}
+Un aspetto di cui bisogna tenere conto, e che ritornerà in seguito, è che ci
+sono una serie di limiti a cui la trasmissione dei dati attraverso i vari
+livelli del protocollo deve sottostare, limiti che è opportuno tenere presente
+perché in certi casi si possono avere delle conseguenze sul comportamento
+delle applicazioni.
+Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
+loro origini ed alle eventuali implicazioni che possono avere:
+\begin{itemize}
+\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}).
+\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
+ 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}
-\chapter{Socket TCP elementari}
-
-Esamineremo in questo capitolo quanto necessario per capire come scrivere un
-client e un server TCP, riprendendo quanto visto in \ref{sec:net_cli_sample} e
-\ref{sec:net_cli_server}.
-
-
-
-\subsection{Creazione e terminazione della connessione TCP}
-
-Per capire il funzionamento delle funzioni della interfaccia dei socket che
-operano con TCP (le varie \texttt{connect}, \texttt{accept}, \texttt{close}
-che abbiamo visto negli esempi iniziali e su cui torneremo più avatni) è
-fodamentale capire come funziona la creazione e la conclusione di una
-connessione TCP.
-
-
-
-
-\subsection{Le porte}
-
+\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}, 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 \ref{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
+frammentano i pacchetti che trasmettono (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.
+
+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
+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 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
+
+
+\subsection{Il passaggio dei dati in TCP}
+\label{sec:net_tcp_pass}
+
+\subsection{Il passaggio dei dati in UDP}
+\label{sec:net_udp_pass}