%% network.tex
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 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 "Un preambolo",
dati.
+\subsection{Il modello \textit{broadcast}}
+\label{sec:net_broadcast}
+
+Uno specifico modello relativo alla programmazione di rete è poi quello in cui
+è possibile, invece della classica comunicazione uno ad uno comunque usata in
+tutti i modelli precedenti (anche nel \texttt{peer to peer} la comunicazione è
+comunque fra singoli ``\textit{peer}''), una comunicazione da uno a molti.
+
+\itindbeg{broadcast}
+
+Questo modello nasce dal fatto che molte tecnologie di rete (ed in particolare
+la Ethernet, che è probabilmente la più diffusa) hanno il supporto per
+effettuare una comunicazione in cui un nodo qualunque della rete più inviare
+informazioni in contemporanea a tutti gli altri. In questo caso si parla di
+\textit{broadcast}, utilizzando la nomenclatura usata per le trasmissioni
+radio, anche se in realtà questo tipo di comunicazione è eseguibile da un nodo
+qualunque per cui tutti quanti possono ricoprire sia il ruolo di trasmettitore
+che quello di ricevitore.
+
+\itindbeg{multicast}
+
+In genere si parla di \textit{broadcast} quando la trasmissione uno a molti è
+possibile fra qualunque nodo di una rete e gli altri, ed è supportata
+direttamente dalla tecnologia di collegamento utilizzata. L'utilizzo di questa
+forma di comunicazione da uno a molti però può risultare molto utile anche
+quando questo tipo di supporto non è disponibile (come ad esempio su Internet,
+dove non si possono contattare tutti i nodi presenti).
+
+\itindend{broadcast}
+
+In tal caso alcuni protocolli di rete (e quelli usati per Internet sono fra
+questi) supportano una variante del\textit{broadcast}, detta
+\textit{multicast}, in cui resta possibile fare una comunicazione uno a molti,
+in cui una applicazione invia i pacchetti a molte altre, in genere passando
+attraverso un opportuno supporto degli apparati ed una qualche forma di
+registrazione che consente la distribuzione della cominicazione ai nodi
+interessati.
+
+\itindend{multicast}
+
+Ovviamente i programmi che devono realizzare un tipo di comunicazione di
+questo tipo (come ad esempio potrebbero essere quelli che effettuano uno
+\textit{streaming} di informazioni) devono rispondere a delle problematiche
+del tutto diverse da quelle classiche illustrate nei modelli precedenti, e
+costituiscono pertanto un'altra classe completamente a parte.
+
+
\section{I protocolli di rete}
\label{sec:net_protocols}
un suo specifico formato. Per applicazioni generiche, come la posta o le
pagine web, viene di solito definito ed implementato quello che viene
chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
- SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
- solito attraverso un RFC\footnote{l'acronimo RFC sta per \textit{Request For
- Comment} ed è la procedura attraverso la quale vengono proposti gli
- standard per Internet.}).
+ SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard, di
+ solito attraverso un RFC (l'acronimo RFC sta per
+ \itindex{Request~For~Comment~(RFC)} \textit{Request For Comment} ed è la
+ procedura attraverso la quale vengono proposti gli standard per Internet).
\item I dati delle applicazioni vengono inviati al livello di trasporto usando
un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
cap.~\ref{cha:socket_intro}). Qui verranno spezzati in pacchetti di
che mostra un panorama sui principali protocolli della famiglia, e delle loro
relazioni reciproche e con alcune dalle principali applicazioni che li usano.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\centering
\includegraphics[width=13cm]{img/tcpip_overview}
\caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
appartengono. Come ICMP viene implementato direttamente sopra IP.
\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
- reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
- Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
- address}) alla interfaccia, ma non serve in connessioni punto-punto.
+ reti di tipo \textit{broadcast} come Ethernet, Token Ring o FDDI che hanno
+ associato un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma
+ non serve in connessioni punto-punto.
\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
routing usato per comunicare lo stato fra gateway vicini a livello di
- \textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
- systems} i raggruppamenti al livello più alto della rete.}, con
+ \textsl{sistemi autonomi} (vengono chiamati \textit{autonomous
+ systems} i raggruppamenti al livello più alto della rete), con
meccanismi che permettono di identificare i vicini, controllarne la
raggiungibilità e scambiare informazioni sullo stato della rete. Viene
implementato direttamente sopra IP.
\subsection{User Datagram Protocol (UDP)}
\label{sec:net_udp}
-UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
-contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
-sostanza esso è una semplice interfaccia al protocollo 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 sez.~\ref{sec:udp_protocol}), 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.
+Il protocollo UDP è un protocollo di trasporto molto semplice; la sua
+descrizione completa è contenuta
+dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in sostanza esso
+è una semplice interfaccia al protocollo 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
+sez.~\ref{sec:udp_protocol}), 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
Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
del tempo di andata e ritorno dei pacchetti fra un client e un server (il
-cosiddetto RTT, \itindex{Round~Trip~Time~(RTT)} \textit{Round Trip Time}), che
-lo rende in grado di adattarsi alle condizioni della rete per non generare
-inutili ritrasmissioni o cadere facilmente in timeout.
+cosiddetto RTT, \textit{Round Trip Time}), che lo rende in grado di adattarsi
+alle condizioni della rete per non generare inutili ritrasmissioni o cadere
+facilmente in timeout.
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
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 suddivisi\footnote{questo
+\textit{frammentazione}, i pacchetti cioè vengono suddivisi in blocchi più
+piccoli che possono essere trasmessi attraverso l'interfaccia.\footnote{questo
accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
- opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
-piccoli che possono essere trasmessi attraverso l'interfaccia.
+ opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}
\begin{table}[!htb]
\centering
\label{tab:net_mtu_values}
\end{table}
+%TODO aggiornare la tabella con dati più recenti
+
\itindbeg{Path~MTU}
La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
\itindend{Path~MTU}
-Infine il TCP definisce una \itindex{Maximum~Segment~Size~(MSS)}
-\textit{Maximum Segment Size} (da qui in avanti abbreviata in MSS) che
-annuncia all'altro capo della connessione la dimensione massima dimensione del
-segmento di dati che può essere ricevuto, così da evitare la
-frammentazione. Di norma viene impostato alla dimensione della MTU
+Infine il TCP definisce una \textit{Maximum Segment Size} o MSS (vedi
+sez.~\ref{sec:tcp_protocol}) che annuncia all'altro capo della connessione la
+dimensione massima del segmento di dati che può essere ricevuto, così da
+evitare la frammentazione. Di norma viene impostato alla dimensione della MTU
dell'interfaccia meno la lunghezza delle intestazioni di IP e TCP, in Linux il
-default, mantenuto nella costante \const{TCP\_MSS} è 512.
+default, mantenuto nella costante \constd{TCP\_MSS} è 512.
\itindend{Maximum~Transfer~Unit~(MTU)}
projects / gapil.git / blobdiff