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
- un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
- 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
- dallo stack TCP, nel caso il protocollo di trasporto usato sia questo.
+ un'interfaccia opportuna (i \textit{socket}, che esamineremo 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 dallo stack TCP,
+ nel caso il protocollo di trasporto usato 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,
che si occupa di inserire le opportune informazioni per poter effettuare
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.
-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 interfaccia di programmazione su questo confine, tanto
-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.
+socket (vedi sez.~\ref{cha:socket_intro}), è 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 interfaccia di programmazione
+su questo confine, tanto 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
IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
a parte applicazioni particolari si preferisce sempre usare i servizi messi a
-disposizione dai due protocolli precedenti. Per questo motivo a parte alcuni
-brevi accenni su IP in questa sezione ci concentreremo sul livello di
+disposizione dai due protocolli precedenti. Per questo, motivo a parte alcuni
+brevi accenni su IP in questa sezione, ci concentreremo sul livello di
trasporto.
\subsection{Internet Protocol (IP)}
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.
+\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
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\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ò
-\textsl{trasmettere} e \textsl{ricevere} da più stazioni usando la stessa
-frequenza.
+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ò \textsl{trasmettere} e \textsl{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 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
+pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
quelle che usano il \textit{multicast}. \itindex{multicast}
\subsection{Transport Control Protocol (TCP)}
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\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
+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 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 degli
\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
scartare i duplicati.
che possono essere ricevuti.
Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
-socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte
+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 ritmo che il
projects / gapil.git / blobdiff