%% network.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2004 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",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
-\part{Programmazione di rete}
-\label{part:progr-di-rete}
-
\chapter{Introduzione alla programmazione di rete}
\label{cha:network}
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
\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: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
\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.
\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
projects / gapil.git / blobdiff