X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=a82f3ec70a17ca089dc086ef071181321530c325;hp=2d9186ea3a779a173ca26529ef6ea3bf622a7127;hb=520fa6e7cd289a93a0955f3f91848ebd5b424250;hpb=d3360b59e957e86e2cc972f1841678feca8eff33

diff --git a/network.tex b/network.tex
index 2d9186e..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
@@ -575,15 +576,16 @@ protocollo IP sono forniti nell'appendice \secref{sec:ip_protocol}.
 \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.
@@ -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