Rifinitura degli indici, correzioni ortografiche varie.

[gapil.git] / network.tex

diff --git a/network.tex b/network.tex
index e0e7d286c00d83e42489b5cb94ca3aa3aa9511f7..671dd3861def6e1e8f8c570fe01ed0eb1f727225 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -191,11 +191,11 @@ La struttura della comunicazione pertanto si pu
   specifico, implementando un protocollo di applicazione (esempi possono
   essere HTTP, POP, telnet, SMTP, etc).
 \item Questi dati vengono inviati al livello di trasporto usando
   specifico, implementando un protocollo di applicazione (esempi possono
   essere HTTP, POP, telnet, SMTP, etc).
 \item Questi dati vengono inviati al livello di trasporto usando

-  un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
-  seguito). Qui verranno spezzati in pacchetti di dimensione opportuna e
-  incapsulati nel protocollo di trasporto, aggiungendo ad ogni pacchetto le
-  informazioni necessarie per la sua gestione. Questo processo viene
-  svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
+  un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
+  in dettaglio in seguito). Qui verranno spezzati in pacchetti di dimensione
+  opportuna e incapsulati nel protocollo di trasporto, aggiungendo ad ogni
+  pacchetto le informazioni necessarie per la sua gestione. Questo processo
+  viene svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il

   protocollo di trasporto sia questo.
 \item Una volta composto il pacchetto nel formato adatto al protocollo di
   trasporto usato questo sarà passato al successivo livello, quello di rete,
   protocollo di trasporto sia questo.
 \item Una volta composto il pacchetto nel formato adatto al protocollo di
   trasporto usato questo sarà passato al successivo livello, quello di rete,


@@ -252,14 +252,14 @@ che operano su 4 livelli diversi. Per gli interessi della programmazione di
 rete però sono importanti principalmente i due livelli centrali, e soprattutto
 quello di trasporto. 
 
 rete però sono importanti principalmente i due livelli centrali, e soprattutto
 quello di trasporto. 
 

-La principale interfaccia di programmazione di rete, quella dei socket, è
-infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
-di sopra del livello di trasporto i programmi hanno a che fare solo con
-dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
-i dettagli relativi alla comunicazione. È pertanto naturale definire una API
-su questo confine tanto più che è proprio li (come evidenziato in
-\figref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
-inserita la divisione fra kernel space e user space.
+La principale interfaccia di programmazione di rete, quella dei
+socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
+Questo avviene perché al di sopra del livello di trasporto i programmi hanno a
+che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
+vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
+naturale definire una API su questo confine tanto più che è proprio li (come
+evidenziato in \figref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non
+solo) viene inserita la divisione fra kernel space e user space.

 
 In realtà in un sistema Unix è possibile accedere anche agli altri livelli
 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
 
 In realtà in un sistema Unix è possibile accedere anche agli altri livelli
 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa


@@ -301,16 +301,17 @@ I vari protocolli mostrati in figura sono i seguenti:
   lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
   orientato alla connessione che provvede un trasporto affidabile e
   lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
   orientato alla connessione che provvede un trasporto affidabile e

-  bidirezionale di un flusso di dati. I socket TCP sono esempi di
-  \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
-  trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È 
+  bidirezionale di un flusso di dati. I socket\index{socket} TCP sono esempi
+  di \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
+  trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È

   usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
   che con IPv6.
 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
   usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
   che con IPv6.
 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza

-  connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
-    socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
-  garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
-  ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
+  connessione a pacchetti. I socket\index{socket} UDP sono esempi di
+  \textit{datagram socket}. Contrariamente al TCP in protocollo non è
+  affidabile e non c'è garanzia che i pacchetti raggiungano la loro
+  destinazione, né sull'eventuale ordine di arrivo. Può essere usato sia con
+  IPv4 che con IPv6.

 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
   errori e trasporta l'informazione di controllo fra stazioni remote e
   instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
   errori e trasporta l'informazione di controllo fra stazioni remote e
   instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente


@@ -407,12 +408,12 @@ UDP 
 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
 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, 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.
+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
 
 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


@@ -433,11 +434,11 @@ viene anche essa trasmessa all'applicazione all'atto del ricevimento.
 Infine UDP è un protocollo che opera senza connessione
 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
 Infine UDP è un protocollo che opera senza connessione
 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni

-in cui un client può scrivere su uno stesso socket pacchetti destinati a
-server diversi, o un server ricevere su un socket pacchetti provenienti da
-client diversi.  Il modo più semplice di immaginarsi il funzionamento di UDP è
-quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
-stazioni usando la stessa frequenza.
+in cui un client può scrivere su uno stesso socket\index{socket} pacchetti
+destinati a server diversi, o un server ricevere su un socket\index{socket}
+pacchetti provenienti da client diversi.  Il modo più semplice di immaginarsi
+il funzionamento di UDP è quello della radio, in cui si può ``trasmettere a''
+e ``ricevere da'' più stazioni usando la stessa frequenza.

 
 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
 
 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
 grande pregio della velocità che in certi casi è essenziale; inoltre si presta


@@ -478,9 +479,9 @@ 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
 
 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

-byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
-segmenti (le unità di dati passate da TCP a IP vengono chiamate
-\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
+byte su un socket\index{socket} TCP, questi potranno essere spezzati dal
+protocollo in due segmenti (le unità di dati passate da TCP a IP vengono
+chiamate \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di

 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,


@@ -494,7 +495,7 @@ cosicch
 essere ricevuti. 
 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 essere ricevuti. 
 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal

-socket ed aumentando con la lettura di quest'ultimo da parte
+socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte

 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il