%% network.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2006 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",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
%% 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}
pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
modello è utilizzato in generale anche per programmi che, come gli esempi che
-abbiamo usato in \capref{cha:IPC} a proposito della comunicazione fra processi
-nello stesso sistema, non fanno necessariamente uso della rete.
+abbiamo usato in cap.~\ref{cha:IPC} a proposito della comunicazione fra
+processi nello stesso sistema, non fanno necessariamente uso della rete.
Normalmente si dividono i server in due categorie principali, e vengono detti
\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
Una caratteristica comune dei protocolli di rete è il loro essere strutturati
in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
realizza le sue funzionalità basandosi su un protocollo del livello
-sottostante. Questo modello di funzionamento è stato stato standardizzato
-dalla \textit{International Standards Organization} (ISO) che ha preparato fin
-dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection}
-(OSI), strutturato in sette livelli, secondo quanto riportato in
-\tabref{tab:net_osilayers}.
+sottostante. Questo modello di funzionamento è stato standardizzato dalla
+\textit{International Standards Organization} (ISO) che ha preparato fin dal
+1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI),
+strutturato in sette livelli, secondo quanto riportato in
+tab.~\ref{tab:net_osilayers}.
\begin{table}[htb]
\centering
Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
- è stata creata la frase \texttt{All people seem to need data processing}, in
+ è stata creata la frase \textit{All people seem to need data processing}, in
cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
-\figref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda solo
-le applicazioni, che viene realizzato in user space, ed un \textit{lower
+fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
+solo le applicazioni, che viene realizzato in user space, ed un \textit{lower
layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
fornite dall'hardware.
\label{sec:net_tcpip_overview}
Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
-(riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in
-\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
-fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
-ad inserirsi all'interno del sistema rispetto alla divisione fra user space e
-kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà è
- sempre possibile accedere dallo user space, attraverso una opportuna
- interfaccia (come vedremo in \secref{sec:sock_sa_packet}), ai livelli
- inferiori del protocollo.}
+(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
+in fig.~\ref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la
+corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
+come essi vanno ad inserirsi all'interno del sistema rispetto alla divisione
+fra user space e kernel space spiegata in
+sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
+ accedere dallo user space, attraverso una opportuna interfaccia (come
+ vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
+ protocollo.}
\begin{table}[htb]
\centering
\hline
\hline
Livello 4&\textit{Application} &\textsl{Applicazione}&
- Telnet, FTP, etc. \\
+ 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}&
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
rete, in genere questi vengono realizzati secondo il modello client-server
- (vedi \secref{sec:net_cliserv}), realizzando una comunicazione secondo un
+ (vedi sez.~\ref{sec:net_cliserv}), realizzando una comunicazione secondo un
protocollo che è specifico di ciascuna applicazione.
\item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
terminali su cui girano gli applicativi, regola il flusso delle
\end{basedescript}
La comunicazione fra due stazioni remote avviene secondo le modalità
-illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
+illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
se in realtà i protocolli di trasmissione usati possono essere molti altri.
\end{figure}
Per chiarire meglio la struttura della comunicazione attraverso i vari
-protocolli mostrata in \figref{fig:net_tcpip_data_flux}, conviene prendere in
+protocolli mostrata in fig.~\ref{fig:net_tcpip_data_flux}, conviene prendere in
esame i singoli passaggi fatti per passare da un livello al sottostante,
la procedura si può riassumere nei seguenti passi:
\begin{itemize}
standard per Internet.}).
\item I dati delle applicazioni vengono inviati al livello di trasporto usando
un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
- in dettaglio in \capref{cha:socket_intro}). Qui verranno spezzati in
+ in dettaglio in cap.~\ref{cha:socket_intro}). Qui verranno spezzati in
pacchetti di dimensione opportuna e inseriti nel protocollo di trasporto,
aggiungendo ad ogni pacchetto le informazioni necessarie per la sua
gestione. Questo processo viene svolto direttamente nel kernel, ad esempio
\section{Il protocollo TCP/IP}
\label{sec:net_tpcip}
-Come accennato in \secref{sec:net_protocols} il protocollo TCP/IP è un insieme
-di protocolli diversi, 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.
+Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un
+insieme di protocolli diversi, 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.
La principale interfaccia usata nella programmazione di rete, quella dei
socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
naturale definire una interfaccia di programmazione su questo confine, tanto
-più che è proprio lì (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.
+più che è proprio lì (come evidenziato in fig.~\ref{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 di
-programmazione (vedi \secref{sec:sock_sa_packet}), ma queste vengono usate
+programmazione (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate
solo quando si debbano fare applicazioni di sistema per il controllo della
rete a basso livello, di uso quindi molto specialistico.
\label{sec:net_tcpip_general}
Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
-molti membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
-mostra un panorama sui principali protocolli della famiglia, e delle loro
+molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
+che mostra un panorama sui principali protocolli della famiglia, e delle loro
relazioni reciproche e con alcune dalle principali applicazioni che li usano.
\begin{figure}[!htbp]
\label{fig:net_tcpip_overview}
\end{figure}
-I vari protocolli riportati in \figref{fig:net_tcpip_overview} sono i
+I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
seguenti:
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
orientato alla connessione che provvede un trasporto affidabile per un
flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
- ritrasmissione, etc. È usato dalla maggior parte delle applicazioni.
+ ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
- protocollo di livello 2 usato per il \textit{multicasting} (vedi
- \secref{sec:xxx_multicast}). Permette alle stazioni remote di notificare ai
- router che supportano questa comunicazione a quale gruppo esse appartengono.
- Come ICMP viene implementato direttamente sopra IP.
+ protocollo di livello 2 usato per il \itindex{multicast}
+ \textit{multicast} (vedi sez.~\ref{sec:xxx_multicast}). Permette
+ alle stazioni remote di notificare ai router che supportano questa
+ comunicazione a quale gruppo esse appartengono. Come ICMP viene
+ implementato direttamente sopra IP.
\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
- reti di tipo broadcast come Ethernet, Token Ring o FDDI che hanno associato
- un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma non serve
- in connessioni punto-punto.
+ reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
+ Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
+ address}) alla interfaccia, ma non serve in connessioni punto-punto.
\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
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
dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
+realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
all'altro della rete; le caratteristiche essenziali con cui questo viene
realizzato in IPv4 sono due:
internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
problemi si è perciò definita una nuova versione del protocollo, che (saltando
un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
-IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
+IPv4, mantenendone inalterate le funzioni che si sono dimostrate valide,
eliminando quelle inutili e aggiungendone poche altre per mantenere il
protocollo il più snello e veloce possibile.
supportare una gerarchia con più livelli di indirizzamento, un numero di
nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi.
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
- si aggiunge agli usuali \textit{unycast} e \textit{multicast}.
+ si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
+ \textit{multicast}.
\item la semplificazione del formato dell'intestazione (\textit{header}) dei
pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
- eliminare la necessità di riprocessamento della stessa da parte dei router e
+ eliminare la necessità di rielaborazione della stessa da parte dei router e
contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
\item un supporto per le opzioni migliorato, per garantire una trasmissione
più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
\end{itemize}
Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
-protocollo IP sono forniti nell'appendice \secref{sec:ip_protocol}.
+protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
\subsection{User Datagram Protocol (UDP)}
\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 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
pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
questo di nuovo deve tenere conto l'applicazione.
-Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
+Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
destinazione esso viene passato all'applicazione ricevente in tutta la sua
lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
viene anche essa trasmessa all'applicazione all'atto del ricevimento.
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 multicasting.
+quelle che usano il \textit{multicast}. \itindex{multicast}
\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.
Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
del tempo di andata e ritorno dei pacchetti fra un client e un server (il
-cosiddetto RTT, \textit{round-trip time}), che lo rende in grado di adattarsi
-alle condizioni della rete per non generare inutili ritrasmissioni o cadere
-facilmente in timeout.
+cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
+rende in grado di adattarsi alle condizioni della rete per non generare
+inutili ritrasmissioni o 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
del controllo di flusso e della gestione della sequenzialità dei dati viene
effettuato per entrambe le direzioni di comunicazione.
+% TODO mettere riferimento alla appendice su TCP quando ci sarà
%% Una descrizione più accurata del protocollo è fornita in appendice
-%% \secref{sec:tcp_protocol}.
+%% sez.~\ref{sec:tcp_protocol}.
\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
\label{sec:net_lim_dim}
Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
-ritornerà anche più avanti, è che ci sono una serie di limiti a cui la
-trasmissione dei dati attraverso i vari livelli del protocollo deve
-sottostare, limiti che è opportuno tenere presente perché in certi casi si
-possono avere delle conseguenze sul comportamento delle applicazioni.
+ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
+una serie di limiti a cui la trasmissione dei dati attraverso i vari livelli
+del protocollo deve sottostare; limiti che è opportuno tenere presente perché
+in certi casi si possono avere delle conseguenze sul comportamento delle
+applicazioni.
Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
alle eventuali implicazioni che possono avere, è il seguente:
\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
campo apposito nell'header di IP che è lungo 16 bit (vedi
- \figref{fig:IP_ipv4_head}).
+ fig.~\ref{fig:IP_ipv4_head}).
\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
un pacchetto usando la \textit{jumbo payload option}.
-\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
- dipende dal protocollo specifico usato al livello di connessione fisica. Il
- più comune è quello di ethernet che è pari a 1500 byte, una serie di altri
- valori possibili sono riportati in \tabref{tab:net_mtu_values}.
+\item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit}
+ (\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
+ al livello di connessione fisica. Il più comune è quello di ethernet che è
+ pari a 1500 byte, una serie di altri valori possibili sono riportati in
+ tab.~\ref{tab:net_mtu_values}.
\end{itemize}
+\itindbeg{Maximum~Transfer~Unit}
Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
dimensioni eccedono la MTU viene eseguita la cosiddetta
\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
- opportuna opzione, si veda \secref{sec:ipv6_protocol}.}) in blocchi più
+ opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
piccoli che possono essere trasmessi attraverso l'interfaccia.
\begin{table}[!htb]
X.25 & 576 \\
\hline
\end{tabular}
- \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
- reti diverse.}
+ \caption{Valori della MTU (\textit{Maximum Transfer Unit}) per una serie di
+ diverse tecnologie di rete.}
\label{tab:net_mtu_values}
\end{table}
La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
- MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
+ MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
conto che non è affatto detto che la \textit{path MTU} sia la stessa in
entrambe le direzioni, perché l'instradamento può essere diverso nei due
\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
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
\const{TCP\_MSS} è 512.
-%\subsection{Il passaggio dei dati in TCP}
-%\label{sec:net_tcp_pass}
-
-%\subsection{Il passaggio dei dati in UDP}
-%\label{sec:net_udp_pass}
-
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
+% LocalWords: TCP multitasking client ftp telnet ssh cap thread peer to three
+% LocalWords: Napster routing tier two middle International Standards Systems
+% LocalWords: Organization Interconnection tab Application Presentation All of
+% LocalWords: Session Transport DataLink Physical people seem need processing
+% 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: 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: Shortest Path First Generic Encapsulation Authentication Header
+% LocalWords: IPSEC ESP Encapsulating Security Payload Point Line over raw QoS
+% LocalWords: dall' Universal addressing Best effort unicast header dell' RTT
+% LocalWords: datagram connectionless streaming nell' acknowlegment trip flow
+% LocalWords: segment control advertised window nell'header dell'header option
+% LocalWords: payload MTU Transfer Unit Hyperlink IBM Mbit sec IEEE path but
+% LocalWords: dell'MTU destination unreachable fragmentation needed packet too
+% LocalWords: big discovery MSS Size
projects / gapil.git / blobdiff