Aggiornamento note copyright e I/O Asyncrono

[gapil.git] / netlayer.tex

diff --git a/netlayer.tex b/netlayer.tex
index 2db12f07b0528a1a12d591ea9563d7d5be866851..9e8d27c41e45d906351e20ae0752356ba68b82d1 100644 (file)
--- a/netlayer.tex
+++ b/netlayer.tex
@@ -1,6 +1,6 @@
 %% netlayer.tex
 %%
-%% Copyright (C) 2000-2011 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2015 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",
@@ -155,7 +155,7 @@ Come si può notare però la suddivisione riportata in
 tab.~\ref{tab:IP_ipv4class} è largamente inefficiente in quanto se ad un
 utente necessita anche solo un indirizzo in più dei 256 disponibili con una
 classe A occorre passare a una classe B, che ne prevede 65536,\footnote{in
-  realtà i valori esatti sarebbero 254 e 65536, una rete con a disposizione
+  realtà i valori esatti sarebbero 254 e 65534, una rete con a disposizione
   $N$ bit dell'indirizzo IP, ha disponibili per le singole macchine soltanto
   $@^N-2$ numeri, dato che uno deve essere utilizzato come indirizzo di rete e
   uno per l'indirizzo di \itindex{broadcast} \textit{broadcast}.} con un
@@ -214,7 +214,7 @@ praticamente ogni protocollo di rete) una opportuna intestazione in cima ai
 dati che deve trasmettere, la cui schematizzazione è riportata in
 fig.~\ref{fig:IP_ipv4_head}.
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering
   \includegraphics[width=10cm]{img/ipv4_head}
   \caption{L'intestazione o \textit{header} di IPv4.}
@@ -229,7 +229,7 @@ pacchetto (cioè l'indirizzo assegnato alla macchina che lo spedisce) e quello
 \textsl{destinazione} che indica l'indirizzo a cui deve essere inviato il
 pacchetto (cioè l'indirizzo assegnato alla macchina che lo riceverà).
 
-\begin{table}[!hbt]
+\begin{table}[!htb]
   \footnotesize
   \begin{center}
     \begin{tabular}{|l|c|p{10cm}|}
@@ -509,7 +509,7 @@ rispettivamente in tab.~\ref{tab:IP_ipv6field} e tab.~\ref{tab:IP_ipv4field})
 %   \end{center}
 % \end{table}
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering
   \includegraphics[width=10cm]{img/ipv6_head}
   \caption{L'intestazione o \textit{header} di IPv6.}
@@ -611,7 +611,7 @@ quello di IPv6 sono le seguenti:
   frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
   capi della comunicazione (usando un'apposita estensione vedi
   sez.~\ref{sec:IP_ipv6_extens}).
-\item IPv6 richiede il supporto per il \itindex{Maximum~Transfer~Unit}
+\item IPv6 richiede il supporto per il \itindex{Maximum~Transfer~Unit~(MTU)}
   \textit{path MTU discovery} (cioè il protocollo per la selezione della
   massima lunghezza del pacchetto); seppure questo sia in teoria opzionale,
   senza di esso non sarà possibile inviare pacchetti più larghi della
@@ -1475,8 +1475,6 @@ Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di
 quella mostrata in fig.~\ref{fig:ESP_criptopack}, tutti i campi sono in chiaro
 fino al vettore di inizializzazione, il resto è crittografato.
 
-
-
 \begin{figure}[!htb]
   \centering
   \includegraphics[width=10cm]{img/esp_option}
@@ -1576,7 +1574,7 @@ Il protocollo ICMP è estremamente semplice, ed il suo unico scopo è quello di
 inviare messaggi di controllo; in fig.~\ref{fig:ICMP_header} si è riportata la
 struttura dell'intestazione di un pacchetto ICMP generico. 
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/icmp_head}
   \caption{L'intestazione del protocollo ICMP.}
   \label{fig:ICMP_header}