X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=dde8230c6171e0e27670efe095c373c0007cfb11;hp=490112b816f839196374cfcf4a034ece60a40181;hb=26f7a8bb19c6cb198c213757a97b6ac79e40db4b;hpb=7208522fd60468969d96dba5d8dd2cbd24b75b89

diff --git a/network.tex b/network.tex
index 490112b..dde8230 100644
--- a/network.tex
+++ b/network.tex
@@ -1,6 +1,6 @@
 %% network.tex
 %%
-%% Copyright (C) 2000-2015 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2019 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",
@@ -14,9 +14,9 @@
 
 In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
 come prerequisiti per capire la programmazione di rete, non tratteremo quindi
-aspetti specifici ma faremo una breve introduzione al modello più comune usato
+aspetti specifici ma faremo una breve introduzione ai modelli più comuni usati
 nella programmazione di rete, per poi passare ad un esame a grandi linee dei
-protocolli di rete e di come questi sono organizzati e interagiscono. 
+protocolli di rete e di come questi sono organizzati e interagiscono.
 
 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
 programmazione, ci concentreremo sul gruppo di protocolli più diffuso, il
@@ -29,7 +29,6 @@ programmi.
 \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à
@@ -163,15 +162,15 @@ dati.
 
 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 è
+tutti i modelli precedenti (anche nel \textit{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
+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
@@ -369,10 +368,10 @@ la procedura si può riassumere nei seguenti passi:
   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
@@ -439,9 +438,9 @@ programmazione di rete però sono importanti principalmente i due livelli
 centrali, e soprattutto quello di trasporto.
 
 La principale interfaccia usata nella programmazione di rete, quella dei
-socket (vedi sez.~\ref{cha:socket_intro}), è 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
+socket (che vedremo in sez.~\ref{cha:socket_intro}), è 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
@@ -494,9 +493,9 @@ seguenti:
 \item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
   orientato alla connessione che provvede un trasporto affidabile per un
   flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
-  di tutti gli aspetti del trasporto, come l'\textit{acknoweledgment} (il
-  ricevuto), i timeout, la ritrasmissione, ecc. È usato dalla maggior parte
-  delle applicazioni.
+  di tutti gli aspetti del trasporto dei dati, come l'\textit{acknowledgment}
+  (il ricevuto), i timeout, la ritrasmissione, ecc. È usato dalla maggior
+  parte delle applicazioni.
 \item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
   connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
   protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
@@ -516,9 +515,9 @@ seguenti:
   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
@@ -527,8 +526,8 @@ seguenti:
   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. 
@@ -568,18 +567,19 @@ trasporto.
 \subsection{Internet Protocol (IP)}
 \label{sec:net_ip}
 
-Quando si parla di IP ci si riferisce in genere alla versione attualmente in
-uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
-venne standardizzata nel 1981
+Quando si parla di \textit{Internet Protocol} (IP) si fa in genere riferimento
+ad una versione (la quarta, da cui il nome IPv4) che è quella più usata
+comunemente, anche se ormai si sta diffondendo sempre di più la nuova versione
+IPv6. Il protocollo IPv4 venne standardizzato nel 1981
 dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
 
-Internet Protocol nasce per disaccoppiare le applicazioni della struttura
-hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
-dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
-Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
-all'altro della rete; le caratteristiche essenziali con cui questo viene
-realizzato in IPv4 sono due:
+Il protocollo IP (indipendentemente dalla versione) nasce per disaccoppiare le
+applicazioni della struttura hardware delle reti di trasmissione, e creare una
+interfaccia di trasmissione dei dati indipendente dal sottostante substrato di
+interconnessione fisica, che può essere realizzato con le tecnologie più
+disparate (Ethernet, Token Ring, FDDI, ecc.).  Il compito di IP è pertanto
+quello di trasmettere i pacchetti da un computer all'altro della rete; le
+caratteristiche essenziali con cui questo viene realizzato in sono due:
 
 \begin{itemize}
 \item \textit{Universal addressing} la comunicazione avviene fra due stazioni
@@ -627,17 +627,18 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
 \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
@@ -698,9 +699,9 @@ 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 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
@@ -772,11 +773,11 @@ alle eventuali implicazioni che possono avere, è il seguente:
 
 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
@@ -798,6 +799,8 @@ piccoli che possono essere trasmessi attraverso l'interfaccia.
   \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
@@ -840,13 +843,12 @@ conoscere da subito il \textit{path MTU}.
 
 \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)}