Aggiornamento al 2010 delle note di copyright

[gapil.git] / network.tex

diff --git a/network.tex b/network.tex
index 15459e0073ceb56bbf195a5ddffc4db4b07cedb1..0e549c9a04f83d4d8b88328ba1b9fed1e56a2c00 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -1,6 +1,6 @@
 %% network.tex
 %%
 %% network.tex
 %%

-%% Copyright (C) 2000-2006 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2010 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",
 %% 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",


@@ -8,6 +8,7 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%

+

 \chapter{Introduzione alla programmazione di rete}
 \label{cha:network}
 
 \chapter{Introduzione alla programmazione di rete}
 \label{cha:network}
 


@@ -72,11 +73,12 @@ una risposta alla richiesta. Una volta completata la risposta il server
 diventa di nuovo disponibile.
 
 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
 diventa di nuovo disponibile.
 
 Un \textsl{server concorrente} al momento di trattare la richiesta crea un

-processo figlio (o un thread) incaricato di fornire i servizi richiesti, per
-porsi immediatamente in attesa di ulteriori richieste. In questo modo, con
-sistemi multitasking, più richieste possono essere soddisfatte
-contemporaneamente. Una volta che il processo figlio ha concluso il suo lavoro
-esso di norma viene terminato, mentre il server originale resta sempre attivo.
+processo figlio (o un \itindex{thread} \textit{thread}) incaricato di fornire
+i servizi richiesti, per porsi immediatamente in attesa di ulteriori
+richieste. In questo modo, con sistemi multitasking, più richieste possono
+essere soddisfatte contemporaneamente. Una volta che il processo figlio ha
+concluso il suo lavoro esso di norma viene terminato, mentre il server
+originale resta sempre attivo.

 
 
 \subsection{Il modello \textit{peer-to-peer}}
 
 
 \subsection{Il modello \textit{peer-to-peer}}


@@ -254,12 +256,12 @@ sez.~\ref{sec:intro_unix_struct}.\footnote{in realt
     \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
     \hline
     \hline
     \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
     \hline
     \hline

-    Livello 4&\textit{Application} &\textsl{Applicazione}& 
-    Telnet, FTP, ecc. \\ 
-    Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ 
-    Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP)  \\ 
-    Livello 1&\textit{Link} &\textsl{Collegamento}& 
-    device driver \& scheda di interfaccia  \\
+    Livello 4 & \textit{Application} & \textsl{Applicazione}& 
+                                       Telnet, FTP, ecc. \\ 
+    Livello 3 & \textit{Transport}   & \textsl{Trasporto} & TCP, UDP\\ 
+    Livello 2 & \textit{Network}     & \textsl{Rete}      & IP, (ICMP, IGMP)\\ 
+    Livello 1 & \textit{Link}        & \textsl{Collegamento}& 
+                                       Device driver \& scheda di interfaccia\\

     \hline
 \end{tabular}
 \caption{I quattro livelli del protocollo TCP/IP.}
     \hline
 \end{tabular}
 \caption{I quattro livelli del protocollo TCP/IP.}


@@ -316,7 +318,7 @@ la procedura si pu
   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
   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
+  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.}).
 \item I dati delle applicazioni vengono inviati al livello di trasporto usando
       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


@@ -350,15 +352,15 @@ possa sopportare il carico in transito, ma permettere ai singoli nodi di
 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
 errati o non recapitabili.
 
 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
 errati o non recapitabili.
 

-L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
-di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
-natura inaffidabile, in quanto non è assicurata né una percentuale di
-successo né un limite sui tempi di consegna dei pacchetti.
+L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
+di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
+inaffidabile, in quanto non è assicurata né una percentuale di successo né un
+limite sui tempi di consegna dei pacchetti.

 
 È il livello di trasporto che si deve occupare (qualora necessiti) del
 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
 
 È il livello di trasporto che si deve occupare (qualora necessiti) del
 controllo del flusso dei dati e del recupero degli errori; questo è realizzato

-dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
-al livello di trasporto o ai livelli superiori.
+dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
+pertanto al livello di trasporto o ai livelli superiori.

 
 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
 terminali di comunicazione, ma possono anche assumere il ruolo di
 
 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
 terminali di comunicazione, ma possono anche assumere il ruolo di


@@ -423,7 +425,6 @@ relazioni reciproche e con alcune dalle principali applicazioni che li usano.
 
 I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
 seguenti:
 
 I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
 seguenti:

-

 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
 \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
 \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su


@@ -434,7 +435,7 @@ seguenti:
 \item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
   a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
   ampliato 128 bit che consente più gerarchie di indirizzi,
 \item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
   a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
   ampliato 128 bit che consente più gerarchie di indirizzi,

-  l'autoconfigurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
+  l'auto-configurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},

   che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
   Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
   vuole essere un sostituto.
   che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
   Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
   vuole essere un sostituto.


@@ -550,7 +551,7 @@ grandi linee nei seguenti punti:
 \begin{itemize}
 \item l'espansione delle capacità di indirizzamento e instradamento, per
   supportare una gerarchia con più livelli di indirizzamento, un numero di
 \begin{itemize}
 \item l'espansione delle capacità di indirizzamento e instradamento, per
   supportare una gerarchia con più livelli di indirizzamento, un numero di

-  nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi.
+  nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi.

 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
   si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
   \textit{multicast}.
 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
   si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
   \textit{multicast}.


@@ -575,17 +576,17 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
 \subsection{User Datagram Protocol (UDP)}
 \label{sec:net_udp}
 
 \subsection{User Datagram Protocol (UDP)}
 \label{sec:net_udp}
 

-UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
+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
 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, 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.
+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
 
 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


@@ -617,7 +618,7 @@ grande pregio della velocit
 presta bene per le applicazioni in cui la connessione non è necessaria, e
 costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
 pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
 presta bene per le applicazioni in cui la connessione non è necessaria, e
 costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
 pacchetti può essere tollerata: ad esempio le applicazioni di streaming e

-quelle che usano il \textit{multicast}. \itindex{multicast}
+quelle che usano il \itindex{multicast} \textit{multicast}.

 
 \subsection{Transport Control Protocol (TCP)}
 \label{sec:net_tcp}
 
 \subsection{Transport Control Protocol (TCP)}
 \label{sec:net_tcp}


@@ -663,10 +664,10 @@ scartare i duplicati.
 
 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
 cioè specifica sempre all'altro capo della trasmissione quanti dati può
 
 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
 cioè specifica sempre all'altro capo della trasmissione quanti dati può

-ricevere tramite una \textit{advertised window} (letteralmente
-\textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di
-ricezione, cosicché nella trasmissione non vengano inviati più dati di quelli
-che possono essere ricevuti.
+ricevere tramite una \itindex{advertised~window} \textit{advertised window}
+(letteralmente ``\textsl{finestra annunciata}''), che indica lo spazio
+disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
+inviati più dati di quelli che possono essere ricevuti.

 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 socket ed aumentando con la lettura di quest'ultimo da parte
 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 socket ed aumentando con la lettura di quest'ultimo da parte


@@ -702,7 +703,7 @@ alle eventuali implicazioni che possono avere, 
   l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
   campo apposito nell'header di IP che è lungo 16 bit (vedi
   fig.~\ref{fig:IP_ipv4_head}).
   l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
   campo apposito nell'header di IP che è lungo 16 bit (vedi
   fig.~\ref{fig:IP_ipv4_head}).

-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;

   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
   dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
   suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
   dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
   suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di


@@ -753,9 +754,9 @@ sensi, con diverse tipologie di rete coinvolte.
 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
 frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
 frammentano i pacchetti che ritrasmettono (anche se possono frammentare i

-pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
-volta frammentati i pacchetti possono essere riassemblati solo alla
-destinazione.
+pacchetti che generano loro stessi), al contrario di quanto fanno i router
+IPv4. In ogni caso una volta frammentati i pacchetti possono essere
+riassemblati solo alla destinazione.

 
 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
 
 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
 pacchetto non deve essere frammentato; un router che riceva un pacchetto le


@@ -769,9 +770,9 @@ di tipo \textit{packet too big}.
 Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
 comporta inefficienza, normalmente viene utilizzato un procedimento, detto
 \textit{path MTU discovery} che permette di determinare il \textit{path MTU}
 Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
 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
+fra due stazioni; per la realizzazione del procedimento si usa il flag
+\texttt{DF} di IPv4 e il comportamento normale di IPv6 inviando delle
+opportune serie di 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.
 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.


@@ -780,17 +781,17 @@ Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 
 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
 conoscere da subito il \textit{path MTU}.
 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
 conoscere da subito il \textit{path MTU}.

-\itindend{Maximum~Transfer~Unit}
-

 
 

-
-Infine TCP definisce una MSS \textit{Maximum Segment Size} 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 dell'interfaccia meno la lunghezza
-delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
+Infine TCP definisce una \itindex{Maximum~Segment~Size} \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 dell'interfaccia meno la lunghezza delle
+intestazioni di IP e TCP, in Linux il default, mantenuto nella costante

 \const{TCP\_MSS} è 512.
 
 \const{TCP\_MSS} è 512.
 

+\itindend{Maximum~Transfer~Unit}
+

 
 %%% Local Variables: 
 %%% mode: latex
 
 %%% Local Variables: 
 %%% mode: latex


@@ -804,7 +805,7 @@ delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
 % LocalWords:  fig upper layer lower kernel DoD Department Defense Connection
 % LocalWords:  sez UDP ICMP IGMP device Trasmission Control Protocol l'IP l'UDP
 % LocalWords:  IPv ethernet SMTP RFC Request For Comment socket stack PPP ARP
 % LocalWords:  fig upper layer lower kernel DoD Department Defense Connection
 % LocalWords:  sez UDP ICMP IGMP device Trasmission Control Protocol l'IP l'UDP
 % LocalWords:  IPv ethernet SMTP RFC Request For Comment socket stack PPP ARP

-% LocalWords:  router instradatori version RARP l'autoconfigurazione anycast Di
+% LocalWords:  router instradatori version RARP anycast Di

 % LocalWords:  l'acknoweledgment Datagram Message host ping ICPMv ICMPv Group
 % LocalWords:  multicast Address Resolution broadcast Token FDDI MAC address DF
 % LocalWords:  Reverse EGP Exterior Gateway gateway autonomous systems OSPF GRE
 % LocalWords:  l'acknoweledgment Datagram Message host ping ICPMv ICMPv Group
 % LocalWords:  multicast Address Resolution broadcast Token FDDI MAC address DF
 % LocalWords:  Reverse EGP Exterior Gateway gateway autonomous systems OSPF GRE