X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=fc5113d46d65a4834e286ae46f4b36db1da8be1b;hp=a1c04b71ca34b7cfb7fdf55df68e622f1ca278eb;hb=66765a9be9a61085dd00abd92d99a24b23dc844b;hpb=8f0266fc964bcdf2aa8d7791a24f05a0eda77556 diff --git a/network.tex b/network.tex index a1c04b7..fc5113d 100644 --- a/network.tex +++ b/network.tex @@ -1,7 +1,7 @@ \chapter{Introduzione alla programmazione di rete} \label{cha:network} -In questo capitolo sarà fatta un'introduzione ai contetti generali che servono +In questo capitolo sarà fatta un'introduzione ai concetti generali che servono 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 @@ -62,7 +62,7 @@ estensivamente pi 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. +restituisce l'ora locale della macchina a cui si effettua la richiesta. \begin{figure}[!htb] @@ -124,7 +124,7 @@ int main(int argc, char *argv[]) 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 -può essere compilato su una qualunque macchina linux. +può essere compilato su una qualunque macchina Linux. Il programma anzitutto include gli header necessari (\texttt{\small 1--5}); dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa @@ -151,7 +151,7 @@ comando. Usando la funzione \texttt{connect} sul socket creato in precedenza (\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il -server specificato dall'indirizzo immesso nella struttura possata come secondo +server specificato dall'indirizzo immesso nella struttura passata come secondo argomento, il terzo argomento è la dimensione di detta struttura. Dato che esistono diversi tipi di socket, si è dovuto effettuare un cast della struttura inizializzata in precedenza, che è specifica per i socket IPv4. Un @@ -290,7 +290,7 @@ nuovo socket viene chiuso (\texttt{\small 54}). Il tutto è inserito in un loop infinito (\texttt{\small 42--55}) in modo da poter ripetere l'invio della data ad una successiva connessione. -È impostante notare che questo server è estremamente elementare, infatti a +È importante notare che questo server è estremamente elementare, infatti a parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è scritto per essere lanciato da linea di comando, se lo si volesse utilizzare @@ -354,8 +354,8 @@ della Difesa Americano. \begin{figure}[!htbp] \centering - \caption{Struttura a livelli dei protocolli OSi e TCP/IP, con la - relative corrispondeze e la divisione fra kernel e user space.} + \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la + relative corrispondenze e la divisione fra kernel e user space.} \label{fig:net_osi_tcpip_comp} \end{figure} @@ -384,7 +384,7 @@ operativo rispetto alla divisione fra user space e kernel space spiegata in device driver \& scheda di interfaccia \\ \hline \end{tabular} -\caption{I quattro livelli del protocollo TPC/IP.} +\caption{I quattro livelli del protocollo TCP/IP.} \label{tab:net_layers} \end{table} @@ -396,7 +396,7 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP \begin{description} \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in - genere questi vengono realizzati secondo il modello Client-Server (vedi + genere questi vengono realizzati secondo il modello client-server (vedi \secref{sec:net_cliserv}. \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni terminali su cui girano gli applicativi, regola il flusso delle @@ -435,7 +435,7 @@ opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le informazioni necessarie alla gestione di quest'ultimo. Questo processo viene -svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il +svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il protocollo di trasporto sia questo. Una volta composto il pacchetto nel formato adatto al protocollo di trasporto @@ -510,7 +510,7 @@ della rete a basso livello, un uso quindi molto specialistico, e che non rientra in quanto trattato qui. In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP, -concentrandoci per le ragioni esposte sul livello di trasposto. All'interno di +concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge nella maggior parte delle applicazioni. @@ -518,7 +518,7 @@ nella maggior parte delle applicazioni. Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui -vari prottocolli della famiglia, e delle loro relazioni reciproche e con +vari protocolli della famiglia, e delle loro relazioni reciproche e con alcune dalle principali applicazioni che li usano. \begin{figure}[!htbp] @@ -533,7 +533,7 @@ I vari protocolli mostrati in figura sono i seguenti: \begin{list}{}{} \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 - cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione + cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione dei pacchetti TCP, UDP, ICMP e IGMP. \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua @@ -624,7 +624,7 @@ grandi linee nei seguenti punti: \item la semplificazione del formato della testata, eliminando o rendendo opzionali alcuni dei campi di IPv4, per eliminare la necessità di riprocessamento della stessa da parte dei router e contenere l'aumento di - dimensione dovuto all'ampiamento degli indirizzi + dimensione dovuto all'ampliamento degli indirizzi \item un supporto per le opzioni migliorato, per garantire una trasmissione più efficiente del traffico normale, limiti meno stringenti sulle dimensioni delle opzioni, e la flessibilità necessaria per introdurne di nuove in @@ -642,7 +642,7 @@ 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 è +UDP è un protocollo di trasporto molto semplice, la sua descrizione 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 @@ -673,7 +673,7 @@ Infine UDP (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni in cui un client può scrivere su uno stesso socket pacchetti destinati a -server diversi, o un server ricevere su un socket paccetti provenienti da +server diversi, o un server ricevere su un socket pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più stazioni usando la stessa frequenza. @@ -692,7 +692,7 @@ diverso da UDP; alla base del suo design infatti non stanno semplicit velocità, ma la ricerca della massima affidabilità possibile nella trasmissione dei dati. -La prima differenza con UDP è che TCP provvede sempre una conessione diretta +La prima differenza con UDP è che TCP provvede sempre una connessione diretta fra un client e un server, attraverso la quale essi possono comunicare; per questo il paragone più appropriato per questo protocollo è quello del collegamento telefonico, in quanto prima viene stabilita una connessione fra @@ -729,7 +729,7 @@ Il protocollo provvede anche un controllo di flusso (\textit{flow control}), cioè specifica sempre all'altro capo della trasmissione quanti dati può ricevere tramite una \textit{advertised window} (letteralmente finestra annunciata), che indica lo spazio disponibile nel buffer di ricezione, -cosicchè nella trasmissione non vengano inviati più dati di quelli che possono +cosicché nella trasmissione non vengano inviati più dati di quelli che possono essere ricevuti. Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal @@ -806,7 +806,7 @@ La MTU pi 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 +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ò @@ -824,15 +824,15 @@ messaggio di errore ICMPv4 di tipo \textit{destination unreachable, 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}. +un messaggio di errore ICMPv6 di tipo \textit{packet 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 + MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di 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. +inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC~1191 +per IPv4 e l'RFC~1981 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