\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
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]
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
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
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
\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}
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}
\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
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
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.
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]
\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
\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
\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
(\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.
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
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
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ò
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
projects / gapil.git / blobdiff