X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=fd9f734f9120af57afce588b4941ab1de9aa271f;hp=18d4ef6ba0134bab9efe88d801738f2837962c91;hb=efd164169524125422cf9bb80ff70a0b037886a0;hpb=87372ca8a15e3e43210e42425a232579a6d79036 diff --git a/network.tex b/network.tex index 18d4ef6..fd9f734 100644 --- a/network.tex +++ b/network.tex @@ -53,12 +53,19 @@ viene terminato, mentre il server originale resta sempre attivo. \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 /* predefined types */ @@ -114,12 +121,6 @@ int main(int argc, char *argv[]) \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 @@ -209,9 +210,7 @@ int main(int argc, char *argv[]) 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"); @@ -322,7 +321,7 @@ macchine diverse conversano tramite lo stesso protocollo. Questo modello di 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 @@ -636,8 +635,8 @@ grandi linee nei seguenti punti: 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)} @@ -746,29 +745,80 @@ stesso tempo, il che poi comporta che quanto dicevamo a proposito del 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 è + 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. +\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} - - +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. + +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 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}. + +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. + +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}