X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=a82f3ec70a17ca089dc086ef071181321530c325;hp=1d2a02b1a93d85f1984c2009263a41d440b8800d;hb=d25090faca15102552d77c38161a8a34b0bac41e;hpb=7479ee9544b4206a618a72fb6fd864e09e08debb

diff --git a/network.tex b/network.tex
index 1d2a02b..a82f3ec 100644
--- a/network.tex
+++ b/network.tex
@@ -1,6 +1,6 @@
 %% network.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2003 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",
@@ -518,7 +518,8 @@ trasporto.
 
 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 dall'RFC~719.
+venne standardizzata 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
@@ -568,22 +569,23 @@ grandi linee nei seguenti punti:
 \end{itemize}
 
 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
-protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
+protocollo IP sono forniti nell'appendice \secref{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'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\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.
+contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{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\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
@@ -621,7 +623,8 @@ quelle che usano il multicasting.
 \subsection{Transport Control Protocol (TCP)}
 \label{sec:net_tcp}
 
-Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
+Il TCP è un protocollo molto complesso, definito
+nell'\href{http://www.ietf.org/rfc/rfc0739.txt}{RFC~739} e completamente
 diverso da UDP; alla base della sua progettazione infatti non stanno
 semplicità e velocità, ma la ricerca della massima affidabilità possibile
 nella trasmissione dei dati.
@@ -680,7 +683,7 @@ del controllo di flusso e della gestione della sequenzialit
 effettuato per entrambe le direzioni di comunicazione.
 
 %% Una descrizione più accurata del protocollo è fornita in appendice
-%% \capref{cha:tcp_protocol}.
+%% \secref{sec:tcp_protocol}.
 
 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
 \label{sec:net_lim_dim}
@@ -714,7 +717,7 @@ dimensioni eccedono la MTU viene eseguita la cosiddetta
 \textit{frammentazione}, i pacchetti cioè vengono suddivisi\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 \secref{cha:ip_protocol}.}) in blocchi più
+  opportuna opzione, si veda \secref{sec:ipv6_protocol}.}) in blocchi più
 piccoli che possono essere trasmessi attraverso l'interfaccia.
 
 \begin{table}[!htb]
@@ -765,8 +768,10 @@ comporta inefficienza, normalmente viene utilizzato un procedimento, detto
 \textit{path MTU discovery} che permette di determinare 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'RFC~1191 per IPv4 e l'RFC~1981 per IPv6)
-fintanto che non si hanno più errori.
+pacchetti (per i dettagli vedere
+l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
+l'\href{http://www.ietf.org/rfc/rfc1981.txt}{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