Poche modifiche nei ritagli di tempo.

diff --git a/Makefile b/Makefile
index aa05f50955ac9cc9428f399029154e601e5dc913..988431ec6b5723b2dfe0169c2a0583109c63cfd9 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -1,3 +1,5 @@
 
 

+
+

 clean: 
        rm -f *.dvi *.log *.ps *.html
\ No newline at end of file
 clean: 
        rm -f *.dvi *.log *.ps *.html
\ No newline at end of file

diff --git a/network.tex b/network.tex
index ba0e7d32084f5904121a0a61fc9eea6e63a7ff7a..531d731e53941084227b5d087f360b74da59b098 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -11,6 +11,42 @@ quello che sta alla base di internet, ed in particolare sulle parti pi
 importanti ai fini della programmazione.  
 
 
 importanti ai fini della programmazione.  
 
 

+\section{Il modello client-server}
+\label{sec:net_cliserv}.
+
+La differenza principale fra un'applicazione di rete e un programma normale è
+che quest'ultima per definizione concerne la comunicazione fra ``processi''
+diversi (che in generale non girano neanche sulla stessa macchina). Questo già
+prefigura un cambiamento completo rispetto all'ottica del ``programma''
+monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
+presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
+diversi.
+
+Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
+sotto Unix in generale) è il modello \textit{client-server} in cui un
+programma di servizio, il \textit{server} riceve un connessione e risponde a
+un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
+definito insieme di servizi.
+
+Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
+servizio che viene fornito tramite la rete, ma il modello è utilizzato in
+generale anche per programmi di uso locale.
+
+Normalmente si dividono i server in due categorie principali,
+\textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento.
+
+Un server iterativo risponde alla richiesta inviando i dati e resta occupato
+(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
+richiesta. Una volta completata la richiesta il server diventa di nuovo
+disponibile.
+
+Un server concorrente al momento di trattare la richiesta crea un processo
+figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
+ulteriori richieste. In questo modo più richieste possono essere soddisfatte
+contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro
+viene terminato, mentre il server originale resta sempre attivo.
+
+

 \section{I protocolli di rete}
 \label{sec:net_protocols}
 
 \section{I protocolli di rete}
 \label{sec:net_protocols}
 


@@ -190,6 +226,12 @@ rete (locale) a basso livello, un uso quindi molto specialistico. Il livello 1
 invece dipende dalle singole applicazioni ed è di nuovo troppo specifico per
 essere affrontato qui.
 
 invece dipende dalle singole applicazioni ed è di nuovo troppo specifico per
 essere affrontato qui.
 

+In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
+ma ci concentreremo principalmente sul livello di trasposto e in particolare
+sul protocollo TCP sia per il ruolo centrale che esso svolge nella maggior
+parte delle applciazioni, sia per la sua complessità che necessita di maggiori
+spiegazioni.
+

 \subsection{Il quadro generale}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
 \subsection{Il quadro generale}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da


@@ -280,8 +322,8 @@ 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,
 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,

-eliminando quelle inutili e aggiungendone poche altre ponendo al contempo una
-grande attenzione a mantenere il protocollo il più snello e veloce possibile.
+eliminando quelle inutili e aggiungendone poche altre per mantenere il
+protocollo il più snello e veloce possibile.

 
 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
 grandi linee nei seguenti punti:
 
 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
 grandi linee nei seguenti punti:


@@ -313,57 +355,117 @@ Per maggiori dettagli riguardo al protocollo si pu
 \label{sec:net_udp}
 
 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
 \label{sec:net_udp}
 
 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è

-contenuta dell'RFC768, ma in sostanza esso è una semplice interfaccia a IP dal
+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
 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
-(\ref{sec:appA_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.
+socket, al pacchetto viene aggiunto un header molto semplice (per una
+descrizione più accurata vedi \ref{sec:appA_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
 
 Pertanto il problema principale che si affronta quando si usa UDP è la

-mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino 
-
+mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
+destinazione occorrerà provvedere con l'applicazione all'interno della quale
+si dovrà inserire tutto quanto necessario a gestire la notifica di
+ricevimento, la ritrasmissione, il timeout. 
+
+Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
+stesso ordine in cui sono stati trasmessi, e può anche accadere che i
+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
+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.
+
+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 paccetti 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
+bene per le applicazioni in cui la connessione non è necessaria e
+costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
+essere tollerata, come quelle che usano il multicasting.

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

+Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
+diverso da UDP; alla base del suo design infatti non stanno semplicità e
+velocità, ma la ricerca della massima affidabilità possibile nella
+trasmissione dei dati.
+
+La prima differenza con UDP è che TCP provvede sempre una conessione diretta
+fra un client e un server, attraverso la quale essi possono comunicare; per
+questo il paragone più appropriato per questo protocollo è quello del
+collegamento telefonico, in quanto prima viene stabilita una connessione fra
+due stazioni su cui poi viene effettuata una comunicazione diretta.
+
+Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
+inviati attraverso una connessione ne viene richiesto un ``ricevuto''
+(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
+ritrasmessi facendo un determinato numero di tentativi intervallati da un
+periodo di tempo crescente, fintanto che la connessione sarà considerata
+fallita o caduta la connessione (con un errore di \textit{time-out}), dopo un
+periodo di tempo che dipende dall'implementazione e che può variare far i
+quattro e i dieci minuti.
+
+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 (il cosiddetto RTT, 
+\textit{round-trip time}) fra un client e un server 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
+bytes 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 bytes, 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,
+all'arrivo sarà comunque possibile riordinare i dati e 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ò
+ricevere tramite una \textit{advertised window} (letteralmente 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
+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
+ricevitore non può sostenere.
+
+Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
+\textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
+stesso tempo, il che poi comporta che quanto dicevamo a proposito del
+controllo di flusso e della gestione della sequenzialità dei dati viene
+effettuato per entrambe le direzioni di comunicazione.
+
+\subsection{Creazione e terminazione della connessione TCP}
+
+Per capire il funzionamento delle funzioni della interfaccia dei socket che
+operano con TCP (come \texttt{connect}, \texttt{accept} e \texttt{close} che
+vedremo più avanti) è fodamentale capire come funziona la creazione e la
+conclusione di una connessione TCP.
+
+
+
+
+\subsection{Le porte}

 
 
 
 

-\section{Il modello client-server}
-\label{sec:net_cliserv}.
-
-La differenza principale fra un'applicazione di rete e un programma normale
-è che quest'ultima per definizione concerne la comunicazione fra
-``processi'' diversi (che in generale non girano neanche sulla stessa
-macchina). Questo già prefigura un cambiamento completo rispetto all'ottica
-del ``programma'' monolitico all'interno del quale vengono eseguite tutte le
-istruzioni, e presuppone un sistema operativo ``multitasking'' in grado di
-eseguire processi diversi.
-
-Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
-sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server} riceve un connessione e risponde a
-un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
-definito insieme di servizi.
-
-Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
-servizio che viene fornito tramite la rete, ma il modello è utilizzato in
-generale anche per programmi di uso locale.
-
-Normalmente si dividono i server in due categorie principali,
-\textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento.
-
-Un server iterativo risponde alla richiesta inviando i dati e resta occupato
-(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
-richiesta. Una volta completata la richiesta il server diventa di nuovo
-disponibile.
-
-Un server concorrente al momento di trattare la richiesta crea un processo
-figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
-ulteriori richieste. In questo modo più richieste possono essere soddisfatte
-contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro
-viene terminato, mentre il server originale resta sempre attivo.
-

diff --git a/socket.tex b/socket.tex
index 786ed5538de8addad5d3a9057a96ae17a20c83d0..4cc999d34818865533ddcab50e8c2cadb0ca500f 100644 (file)
--- a/socket.tex
+++ b/socket.tex
@@ -1,12 +1,16 @@
 \chapter{Socket}
 \label{cha:socket}
 
 \chapter{Socket}
 \label{cha:socket}
 

-I \textit{socket} sono usati come meccanismo di comunicazione fra programmi
-utilizzato in ambito unix (e non solo). La creazione di un socket restituisce
-un file descriptor analogo a quello di una pipe ma a differenza di questa e
-degli altri meccanismi esaminati nel capitolo \ref{cha:ipc} i socket non sono
-limitati alla comunicazione fra processi che girano sulla stessa macchina ma
-possono effettuare la comunicazione anche attraverso la rete.
+Il \textit{socket} (traducibile liberamente come \textsl{manicotto}) è uno dei
+principali meccanismi di comunicazione fra programmi utilizzato in ambito unix
+(e non solo). Il socket costituisce in sostanza un canale di comunicazione fra
+due processi su cui si possono leggere e scrivere dati. 
+
+La creazione di un socket restituisce un file descriptor con un comportamento
+analogo a quello di una pipe ma a differenza di questa e degli altri
+meccanismi esaminati nel capitolo \ref{cha:ipc} i socket non sono limitati
+alla comunicazione fra processi che girano sulla stessa macchina ma possono
+effettuare la comunicazione anche attraverso la rete.

 
 I socket infatti sono la principale API (\textit{Application Program
   Interface}) usata nella programmazione di rete. La loro origine risale al
 
 I socket infatti sono la principale API (\textit{Application Program
   Interface}) usata nella programmazione di rete. La loro origine risale al


@@ -14,9 +18,14 @@ I socket infatti sono la principale API (\textit{Application Program
 sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
 siano state sviluppate interfacce alternative, originate dai sistemi SYSV,
 come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
 sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
 siano state sviluppate interfacce alternative, originate dai sistemi SYSV,
 come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la

-diffusione e la popolarità di quella dei socket (e tantomeno usabilità e
+diffusione e la popolarità di quella dei socket (né tantomeno usabilità e

 flessibilità).
 
 flessibilità).
 

+La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
+utilizzare i socket con i più disparati meccanismi di comunicazione, e non
+solo con la suite dei protocolli TCP/IP, che sarà comunque quella di cui
+tratteremo in maniera più estesa.
+

 
 \section{Concetti base}
 \label{sec:sock_gen}
 
 \section{Concetti base}
 \label{sec:sock_gen}


@@ -61,11 +70,11 @@ tipi di socket, che vengono classificati raggruppandoli in quelli che si
 chiamano \textsl{domini} (\textit{domains}).  La scelta di un dominio equivale
 in sostanza alla scelta di una famiglia di protocolli. Ciascun dominio ha un
 suo nome simbolico che convenzionalmente inizia con \texttt{PF\_} (da
 chiamano \textsl{domini} (\textit{domains}).  La scelta di un dominio equivale
 in sostanza alla scelta di una famiglia di protocolli. Ciascun dominio ha un
 suo nome simbolico che convenzionalmente inizia con \texttt{PF\_} (da

-\textit{protocol family}, altro nome con cui si indicano i domini). 
+\textit{Protocol Family}, altro nome con cui si indicano i domini). 

 
 A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
 
 A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per

-\texttt{AF\_} (da \textit{Address Family}, nome che useremo anche noi; le man
-pages di linux si riferiscono a questi anche come \textit{name space}, nome
+\texttt{AF\_} da \textit{Address Family}, nome che useremo anche noi; le man
+pages di linux si riferiscono a questi anche come \textit{name space}, (nome

 che però il manuale della glibc riserva ai domini) e che identifica il formato
 degli indirizzi usati in quel dominio.
 
 che però il manuale della glibc riserva ai domini) e che identifica il formato
 degli indirizzi usati in quel dominio.
 


@@ -92,7 +101,6 @@ riportate in \ntab.
   \label{tab:net_pf_names}
 \end{table}
 
   \label{tab:net_pf_names}
 \end{table}
 

-

 La scelta di un dominio non comporta però la scelta dello stile di
 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
 La scelta di un dominio non comporta però la scelta dello stile di
 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di