X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=87c56369aaf715b661c32d799055cfdec869da90;hp=2e1d070102d3c4121b5b699f0d282905b20cb4c5;hb=597364c925b229bd9a8ea1a88d5e1ef885757140;hpb=99fa5a06cd27160cf673e3483ad552d32efa2c05

diff --git a/network.tex b/network.tex
index 2e1d070..87c5636 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-2016 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",
@@ -369,10 +369,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
@@ -527,8 +527,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. 
@@ -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)}