+%% network.tex
+%%
+%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
+\part{Programmazione di rete}
+\label{part:progr-di-rete}
+
\chapter{Introduzione alla programmazione di rete}
\label{cha:network}
quello che sta alla base di internet, avendo cura di sottolineare i concetti
più importanti da conoscere per la scrittura dei programmi.
-\section{Il modello client-server}
-\label{sec:net_cliserv}
+
+
+\section{Modelli di programmazione}
+\label{sec:net_prog_model}
+
La differenza principale fra un'applicazione di rete e un programma normale è
-che quest'ultima per definizione concerne la comunicazione fra ``processi''
-diversi (che in generale non girano neanche sulla stessa macchina). Questo già
-prefigura un cambiamento completo rispetto all'ottica del ``programma''
-monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
-presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
-diversi.
-
-Un concetto fondamentale su cui si basa la programmazione di rete sotto Linux
+che quest'ultima per definizione concerne la comunicazione fra processi
+diversi, che in generale non girano neanche sulla stessa macchina. Questo già
+prefigura un cambiamento completo rispetto all'ottica del programma monolitico
+all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
+presuppone un sistema operativo multitasking in grado di eseguire più processi
+contemporaneamente.
+
+In questa prima sezione esamineremo brevemente i principali modelli di
+programmazione in uso. Ne daremo una descrizione assolutamente generica e
+superficiale, che ne illustri le caratteristiche principali, non essendo fra
+gli scopi del testo approfondire questi argomenti.
+
+\subsection{Il modello \textit{client-server}}
+\label{sec:net_cliserv}
+
+Il concetto fondamentale su cui si basa la programmazione di rete sotto Linux
(e sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server}, riceve una connessione e risponde a
-un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
-definito insieme di servizi.
+programma di servizio, il \textit{server}, riceve una richiesta e risponde a
+un programma di utilizzo, il \textit{client}, fornendo a quest'ultimo un
+definito insieme di servizi.
-Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
-servizio che viene fornito tramite la rete, ma il modello è utilizzato in
-generale anche per programmi che non fanno necessariamente uso della rete,
-come il sistema a finestre.
+Infatti seguono questo modello tutti i servizi fondamentali di internet, come
+il le pagine web, ftp, telnet, ssh e praticamente ogni servizio che viene
+fornito tramite la rete, anche se, come abbiamo visto, il modello è utilizzato
+in generale anche per programmi che, come gli esempi che abbiamo usato in
+\capref{cha:IPC} a proposito della comunicazione fra processi nello stesso
+sistema, non fanno necessariamente uso della rete.
Normalmente si dividono i server in due categorie principali, e vengono detti
\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
+\subsection{Il modello \textit{peer-to-perr}}
+\label{sec:net_peertopeer}
+
+Da fare
+
+\subsection{Il modello \textit{three-tier}}
+\label{sec:net_three_tier}
+
+Da fare
+
\section{I protocolli di rete}
\label{sec:net_protocols}
Parlando di reti di computer si parla in genere di un insieme molto vasto ed
eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
-ottica, alle comunicazioni via satellite; per rendere possibile la
+ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
comunicazione attraverso un così variegato insieme di mezzi sono stati
adottati una serie di protocolli, il più famoso dei quali, quello alla base
del funzionamento di internet, è il protocollo TCP/IP.
\label{sec:net_iso_osi}
Una caratteristica comune dei protocolli di rete è il loro essere strutturati
-in livelli sovrapposti; in questo modo un livello superiore esegue richieste
-al livello sottostante e da questo riceve responsi, mentre livelli uguali su
-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 quanto riportato in \ntab.
+in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
+realizza le sue funzionalità basandosi su un protocollo del livello
+sottostante. 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 quanto riportato in
+\tabref{tab:net_osilayers}.
\begin{table}[htb]
\centering
- \begin{tabular}{|l|c|c|l|}
+ \begin{tabular}{|l|c|c|}
\hline
- \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \\
+ \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
\hline
\hline
- Livello 7&\textit{Application} &\textsl{Applicazione}& \\
- Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
- Livello 5&\textit{Session} &\textsl{Sessione}& \\
- Livello 4&\textit{Transport} &\textsl{Trasporto}& \\
- Livello 3&\textit{Network} &\textsl{Rete}& \\
- Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
- Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
+ Livello 7&\textit{Application} &\textsl{Applicazione}\\
+ Livello 6&\textit{Presentation} &\textsl{Presentazione} \\
+ Livello 5&\textit{Session} &\textsl{Sessione} \\
+ Livello 4&\textit{Transport} &\textsl{Trasporto} \\
+ Livello 3&\textit{Network} &\textsl{Rete}\\
+ Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\
+ Livello 1&\textit{Connection} &\textsl{Connessione Fisica} \\
\hline
\end{tabular}
\caption{I sette livelli del protocollo ISO/OSI.}
\label{tab:net_osilayers}
\end{table}
-Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione
-della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
-il lavoro dettagliato di standardizzazione il modello si è rivelato
-sostanzialmente troppo complesso e poco flessibile rispetto a quello,
-precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
-quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
- Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
-della Difesa Americano.
+Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
+serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante il
+lavoro dettagliato di standardizzazione il modello si è rivelato
+sostanzialmente troppo complesso e poco flessibile rispetto a quello
+precedente, il TCP/IP, su cui si basa internet, che è diventato uno standard
+de facto. Il modello di quest'ultimo viene chiamato anche modello DoD (sigla
+che sta per \textit{Department of Defense}), dato che fu sviluppato
+dall'agenzia ARPA per il Dipartimento della Difesa Americano.
\begin{figure}[!htbp]
\centering
\end{figure}
-\subsection{Il modello DoD (TCP/IP)}
+\subsection{Il modello TCP/IP (o DoD)}
\label{sec:net_tcpip_overview}
-Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
-\ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
-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
-\secref{sec:intro_unix_struct}.
+Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
+(riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in
+\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
+fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
+ad inserirsi all'interno di un sistema rispetto alla divisione fra user space
+e kernel space spiegata in \secref{sec:intro_unix_struct}.
\begin{table}[htb]
\centering
\textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
\hline
\hline
- Livello 1&\textit{Application} &\textsl{Applicazione}&
+ Livello 4&\textit{Application} &\textsl{Applicazione}&
Telnet, FTP, etc. \\
- Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
- Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
- Livello 4&\textit{Link} &\textsl{Connessione}&
+ Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
+ Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
+ Livello 1&\textit{Link} &\textsl{Connessione}&
device driver \& scheda di interfaccia \\
\hline
\end{tabular}
\label{tab:net_layers}
\end{table}
-Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
-soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
-compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
-\textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
+Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
+ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
+principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
+ Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
+copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
\begin{description}
-\item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
- genere questi vengono realizzati secondo il modello client-server (vedi
- \secref{sec:net_cliserv}.
+\item \textbf{Applicazione} É relativo ai programmi di interfaccia con la
+ rete, in genere questi vengono realizzati secondo il modello client-server
+ (vedi \secref{sec:net_cliserv}), realizzando una comunicazione secondo un
+ protocollo che è specifico di ciascuna applicazione.
\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
- errori. Il protocollo principale di questo livello è il TCP.
+ informazioni, può fornire un trasporto affidabile, cioè con recupero degli
+ errori o inaffidabile. I protocolli principali di questo livello sono il TCP
+ e l'UDP.
\item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
rete complessa e interconnessa, a questo stesso livello operano i protocolli
per il reperimento delle informazioni necessarie allo smistamento, per lo
\end{description}
-La comunicazione fra due stazioni avviene secondo le modalità illustrate in
-\nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per
-lo scambio di informazione su ciascuno livello.
+La comunicazione fra due stazioni remote avviene secondo le modalità
+illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
+dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
+livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
+se in realtà i protocolli di trasmissione usati possono essere molti altri.
+
\begin{figure}[!htb]
- \centering
- \includegraphics[width=10cm]{img/tcp_data_flux}
+ \centering \includegraphics[width=10cm]{img/tcp_data_flux}
\caption{Strutturazione del flusso dei dati nella comunicazione fra due
applicazioni attraverso i protocolli della suite TCP/IP.}
\label{fig:net_tcpip_data_flux}
\end{figure}
-La struttura della comunicazione pertanto si può riassumere nei seguenti passi:
+La struttura della comunicazione attraverso il TCP/IP si può pertanto
+riassumere nei seguenti passi:
\begin{itemize}
\item Le singole applicazioni si scambieranno i dati secondo un loro formato
specifico, implementando un protocollo di applicazione (esempi possono
essere HTTP, POP, telnet, SMTP, etc).
\item Questi dati vengono inviati al livello di trasporto usando
- un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
- seguito). Qui verranno spezzati in pacchetti di dimensione opportuna e
- incapsulati nel protocollo di trasporto, aggiungendo ad ogni pacchetto le
- informazioni necessarie per la sua gestione. Questo processo viene
- svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
+ un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
+ in dettaglio in seguito). Qui verranno spezzati in pacchetti di dimensione
+ opportuna e incapsulati nel protocollo di trasporto, aggiungendo ad ogni
+ pacchetto le informazioni necessarie per la sua gestione. Questo processo
+ viene svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
protocollo di trasporto sia questo.
\item Una volta composto il pacchetto nel formato adatto al protocollo di
- trasporto usato questo sarà passato al successivo livello, quello del
- collegamento che si occupa di inserire le opportune informazioni per poter
- effettuare l'instradamento nella rete ed il recapito alla destinazione
- finale. In genere questo è il livello di IP (Internet Protocol), a cui
- vengono inseriti i numeri IP che identificano i computer su internet.
+ trasporto usato questo sarà passato al successivo livello, quello di rete,
+ che si occupa di inserire le opportune informazioni per poter effettuare
+ l'instradamento nella rete ed il recapito alla destinazione finale. In
+ genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
+ i numeri IP che identificano i computer su internet.
\item L'ultimo passo è il trasferimento del pacchetto al driver della
interfaccia di trasmissione che si incarica di incapsularlo nel relativo
protocollo di trasmissione fisica usato dall'hardware usato per la
- comunicazione (ad esempio Ethernet per una scheda di rete).
+ comunicazione (ad esempio \textit{ethernet} per una scheda di rete).
\end{itemize}
-\subsection{Criteri generali del design di TCP/IP}
+\subsection{Criteri generali dell'architettura del TCP/IP}
\label{sec:net_tcpip_design}
-La filosofia architetturale di TCP/IP è semplice: costruire una rete che
+La filosofia architetturale del TCP/IP è semplice: costruire una rete che
possa sopportare il carico in transito, ma permettere ai singoli nodi di
scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
errati o non recapitabili.
rete però sono importanti principalmente i due livelli centrali, e soprattutto
quello di trasporto.
-La principale interfaccia di programmazione di rete, quella dei socket, è
-infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
-di sopra del livello di trasporto i programmi hanno a che fare solo con
-dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
-i dettagli relativi alla comunicazione. È pertanto naturale definire una API
-su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
-nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
+La principale interfaccia di programmazione di rete, quella dei
+socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
+Questo avviene perché al di sopra del livello di trasporto i programmi hanno a
+che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
+vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
+naturale definire una interfaccia di programmazione su questo confine tanto
+più che è proprio lì (come evidenziato in \figref{fig:net_osi_tcpip_comp}) che
+nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space e
user space.
-In realtà in un sistema unix è possibile accedere anche agli altri livelli
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli
inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
-è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
-usate solo quando si vogliono fare applicazioni di sistema per il controllo
-della rete a basso livello, un uso quindi molto specialistico, e che non
-rientra in quanto trattato qui.
+è indicata in \figref{fig:net_osi_tcpip_comp} lasciando uno spazio fra UDP e
+TCP), ma queste vengono usate solo quando si vogliono fare applicazioni di
+sistema per il controllo 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 trasporto. All'interno di
-questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
-nella maggior parte delle applicazioni.
+In questa sezione daremo una breve descrizione dei vari protocolli del TCP/IP,
+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.
\subsection{Il quadro generale}
+\label{sec:net_tcpip_general}
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 protocolli della famiglia, e delle loro relazioni reciproche e con
-alcune dalle principali applicazioni che li usano.
+altri membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
+mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni
+reciproche e con alcune dalle principali applicazioni che li usano.
\begin{figure}[!htbp]
\centering
lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
\item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
orientato alla connessione che provvede un trasporto affidabile e
- bidirezionale di un flusso di dati. I socket TCP sono esempi di
- \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
- trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È
+ bidirezionale di un flusso di dati. I socket\index{socket} TCP sono esempi
+ di \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
+ trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È
usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
che con IPv6.
\item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
- connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
- socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
- garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
+ connessione, a pacchetti. I socket\index{socket} UDP sono esempi di
+ \textit{datagram socket}. Contrariamente al TCP il protocollo non è
+ affidabile e non c'è garanzia che i pacchetti raggiungano la loro
+ destinazione, si perdano o vengano duplicati, o abbiano un particolare
ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
\item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
errori e trasporta l'informazione di controllo fra stazioni remote e
volte per durante il boot per assegnare un indirizzo IP ad una macchina.
\item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
-\item \textsl{NETLINK} \textit{Netlink}.
- Provvede l'interfaccia di accesso alla comunicazione a basso livello.
+\item \textsl{NETLINK} \textit{Netlink}. Provvede, in Linux, l'interfaccia di
+ accesso alla comunicazione a basso livello.
\end{list}
-Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
-rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
-basati su IP e sia possibile intervenire a questo livello con i \textit{raw
- socket} questa tecnica è molto meno diffusa e a parte applicazioni
-particolari si preferisce sempre usare i servizi messi a disposizione dai due
-protocolli precedenti. Per questo motivo a parte alcuni brevi accenni su IP
-in questa sezione ci concentreremo sul livello di trasporto.
+Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
+scopi particolari si rifanno dirattamente ad IP (ed i suoi correlati ICMP e
+IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
+questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
+a parte applicazioni particolari si preferisce sempre usare i servizi messi a
+disposizione dai due protocolli precedenti. Per questo motivo a parte alcuni
+brevi accenni su IP in questa sezione ci concentreremo sul livello di
+trasporto.
\subsection{Internet Protocol (IP)}
\label{sec:net_ip}
realizzato in IPv4 sono due:
\begin{itemize}
-\item \textit{Universal addressing} la comunicazione avviene fra due host
- identificati univocamente con un indirizzo a 32 bit che può appartenere ad
- una sola interfaccia di rete.
+\item \textit{Universal addressing} la comunicazione avviene fra due stazioni
+ remote identificate univocamente con un indirizzo a 32 bit che può
+ appartenere ad una sola interfaccia di rete.
\item \textit{Best effort} viene assicurato il massimo impegno nella
trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
percentuale di successo né sul tempo di consegna dei pacchetti di dati.
\begin{itemize}
\item l'espansione delle capacità di indirizzamento e instradamento, per
supportare una gerarchia con più livelli di indirizzamento, un numero di
- nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
+ nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi.
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
- si aggiunge agli usuali \textit{unycast} e \textit{multicast}
-\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'ampliamento degli indirizzi
+ si aggiunge agli usuali \textit{unycast} e \textit{multicast}.
+\item la semplificazione del formato dell'intestazione (\textit{header}) dei
+ pacchetti, 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'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
- futuro
-\item il supporto per delle capacità di qualità di servizio (QoS) che
+ futuro.
+\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
permettano di identificare gruppi di dati per i quali si può provvedere un
trattamento speciale (in vista dell'uso di internet per applicazioni
- multimediali e/o ``real-time'')
+ multimediali e/o ``real-time'').
\end{itemize}
Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
-\subsection{UDP: User Datagram Protocol)}
+\subsection{User Datagram Protocol (UDP)}
\label{sec:net_udp}
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
-protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
-(per una descrizione più accurata vedi \secref{sec:xxx_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.
+protocollo) su un socket\index{socket}, al pacchetto viene aggiunto un header
+molto semplice (per una descrizione più accurata vedi \secref{sec:xxx_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
-destinazione occorrerà provvedere con l'applicazione all'interno della quale
+destinazione occorrerà provvedere con l'applicazione, all'interno della quale
si dovrà inserire tutto quanto necessario a gestire la notifica di
ricevimento, la ritrasmissione, il timeout.
Infine UDP è un protocollo che opera senza connessione
(\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 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.
+in cui un client può scrivere su uno stesso socket\index{socket} pacchetti
+destinati a server diversi, o un server ricevere su un socket\index{socket}
+pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi
+il funzionamento di UDP è quello della radio, in cui si può
+``\textsl{trasmettere a}'' e ``\textsl{ricevere da}'' più stazioni usando la
+stessa frequenza.
Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
grande pregio della velocità che in certi casi è essenziale; inoltre si presta
bene per le applicazioni in cui la connessione non è necessaria e
-costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
-essere tollerata, ad esempio quelle che usano il multicasting.
+costituirebbe solo un peso in termini di prestazioni mentre una perdita di
+pacchetti può essere tollerata, ad esempio le applicazioni di streaming e
+quelle che usano il multicasting.
-\subsection{TCP: Transport Control Protocol)}
+\subsection{Transport Control Protocol (TCP)}
\label{sec:net_tcp}
Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
effettuata.
Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
-inviati attraverso una connessione ne viene richiesto un ``ricevuto''
+inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
-ritrasmessi per un determinato numero di tentativi, intervallati da un
-periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
+ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
+di tempo crescente, fino a che sarà considerata fallita o caduta la
connessione (e generato un errore di \textit{time-out}), dopo un periodo di
-tempo che dipende dall'implementazione e che può variare far i
-quattro e i dieci minuti.
+tempo che dipende dall'implementazione e che può variare far i quattro e i
+dieci minuti.
Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
-byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
-segmenti (le unità di dati passate da TCP a IP vengono chiamate
-\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
+byte su un socket\index{socket} TCP, questi potranno essere spezzati dal
+protocollo in due segmenti (le unità di dati passate da TCP a IP vengono
+chiamate \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
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
-essere ricevuti.
+ricevere tramite una \textit{advertised window} (letteralmente
+\textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di
+ricezione, 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
-socket ed aumentando con la lettura di quest'ultimo da parte
+socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte
dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
-ricevitore non può sostenere.
+ricevente non può sostenere.
Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
\textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
\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 aspetto di cui bisogna tenere conto nella programmazione di rete, e che
+ritornerà anche più avanti, è 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:
+Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
+alle eventuali implicazioni che possono avere, è il seguente:
\begin{itemize}
-\item La dimensione massima di un pacchetti IP è di 65535 byte, compreso
+\item La dimensione massima di un pacchetto IP è di 65535 byte, compreso
l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
apposito nell'header di IP che è lungo 16 bit (vedi
- \tabref{tab:IP_ipv4head}).
+ \figref{fig:IP_ipv4_head}).
\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
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
\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
dipende dal protocollo specifico usato al livello di link. Il più comune è
quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
- sono riportati in \ntab.
+ sono riportati in \tabref{tab:net_mtu_values}.
\end{itemize}
Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
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
+inefficienza, normalmente viene utilizzato il procedimento della \textit{path
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
projects / gapil.git / blobdiff