First git commit
authorSimone Piccardi <piccardi@truelite.it>
Sat, 11 Aug 2018 17:44:07 +0000 (19:44 +0200)
committerSimone Piccardi <piccardi@truelite.it>
Sat, 11 Aug 2018 17:44:07 +0000 (19:44 +0200)
.gitignore [new file with mode: 0644]
gapil.tex
network.tex
tcpsock.tex

diff --git a/.gitignore b/.gitignore
new file mode 100644 (file)
index 0000000..1cd6aa9
--- /dev/null
@@ -0,0 +1,16 @@
+*.aux
+*.bbl
+*.blg
+*.dvi
+*.pdf
+*.ps
+*.idx
+*.log
+*.idx
+*.ilg
+*.ind
+*.roc
+*.tgz
+*.toc
+*.out
+*~
\ No newline at end of file
index 5b819b9..d450732 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -20,7 +20,7 @@
 %inner=2.5cm,outer=1.8cm,bottom=3.3cm,top=2.3cm]{geometry}
 
 \usepackage[paperwidth=18.91cm,paperheight=24.589cm,
-vmargin=1.9cm,inner=1.9cm,outer=2.29cm,bindingoffset=0.89cm]{geometry}
+vmargin=1.9cm,inner=1.9cm,outer=1.9cm,bindingoffset=0.89cm]{geometry}
 
 
 % encodings
@@ -225,3 +225,8 @@ hyperfootnotes=false]{hyperref}
 \bibliography{biblio}
 
 \end{document}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: t
+%%% End:
index 68a50e1..0d39a11 100644 (file)
@@ -163,15 +163,15 @@ dati.
 
 Uno specifico modello relativo alla programmazione di rete è poi quello in cui
 è possibile, invece della classica comunicazione uno ad uno comunque usata in
-tutti i modelli precedenti (anche nel \texttt{peer to peer} la comunicazione è
+tutti i modelli precedenti (anche nel \textit{peer-to-peer} la comunicazione è
 comunque fra singoli ``\textit{peer}''), una comunicazione da uno a molti.
 
 \itindbeg{broadcast}
 
 Questo modello nasce dal fatto che molte tecnologie di rete (ed in particolare
-la Ethernet, che è probabilmente la più diffusa) hanno il supporto per
-effettuare una comunicazione in cui un nodo qualunque della rete più inviare
-informazioni in contemporanea a tutti gli altri. In questo caso si parla di
+Ethernet, che è probabilmente la più diffusa) hanno il supporto per effettuare
+una comunicazione in cui un nodo qualunque della rete più inviare informazioni
+in contemporanea a tutti gli altri. In questo caso si parla di
 \textit{broadcast}, utilizzando la nomenclatura usata per le trasmissioni
 radio, anche se in realtà questo tipo di comunicazione è eseguibile da un nodo
 qualunque per cui tutti quanti possono ricoprire sia il ruolo di trasmettitore
index 9e984ef..344ee30 100644 (file)
@@ -51,11 +51,11 @@ Il processo che porta a creare una connessione TCP viene chiamato
   ci sono una serie di flag usati per gestire la connessione, come SYN, ACK,
   URG, FIN, alcuni di essi, come SYN (che sta per \textit{syncronize})
   corrispondono a funzioni particolari del protocollo e danno il nome al
-  segmento, (per maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).}  di
+  segmento, (per maggiori dettagli si veda sez.~\ref{sec:tcp_protocol}).}  di
 dati che vengono scambiati) che porta alla creazione di una connessione è la
 seguente:
  
-\begin{enumerate}
+\begin{enumerate*}
 \item Il server deve essere preparato per accettare le connessioni in arrivo;
   il procedimento si chiama \textsl{apertura passiva} del socket (in inglese
   \textit{passive open}). Questo viene fatto chiamando la sequenza di funzioni
@@ -81,7 +81,7 @@ seguente:
   funzione \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN
   del server inviando un ACK. Alla ricezione di quest'ultimo la funzione
   \func{accept} del server ritorna e la connessione è stabilita.
-\end{enumerate
+\end{enumerate*}
 
 Il procedimento viene chiamato \textit{three way handshake} dato che per
 realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
@@ -107,8 +107,8 @@ stabilisce la connessione.
 
 Si è accennato in precedenza ai \textsl{numeri di sequenza}, che sono anche
 riportati in fig.~\ref{fig:TCP_TWH}: per gestire una connessione affidabile
-infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
-bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
+infatti il protocollo TCP prevede nell'intestazione la presenza di un numero a
+32 bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
 nella sequenza del flusso corrisponde il primo byte della sezione dati
 contenuta nel segmento.
 
@@ -117,12 +117,12 @@ Il numero di sequenza di ciascun segmento viene calcolato a partire da un
 all'inizio della connessione e trasmesso con il SYN;
 l'\textit{acknowledgement} di ciascun segmento viene effettuato dall'altro
 capo della connessione impostando il flag ACK e restituendo nell'apposito
-campo dell'header un \textit{acknowledge number}) pari al numero di sequenza
-che il ricevente si aspetta di ricevere con il pacchetto successivo; dato che
-il primo pacchetto SYN consuma un byte, nel \textit{three way handshake} il
-numero di \textit{acknowledge} è sempre pari al numero di sequenza iniziale
-incrementato di uno; lo stesso varrà anche (vedi fig.~\ref{fig:TCP_close}) per
-l'\textit{acknowledgement} di un segmento FIN.
+campo dell'intestazione un \textit{acknowledge number}) pari al numero di
+sequenza che il ricevente si aspetta di ricevere con il pacchetto successivo;
+dato che il primo pacchetto SYN consuma un byte, nel \textit{three way
+  handshake} il numero di \textit{acknowledge} è sempre pari al numero di
+sequenza iniziale incrementato di uno; lo stesso varrà anche (vedi
+fig.~\ref{fig:TCP_close}) per l'\textit{acknowledgement} di un segmento FIN.
 
 \index{numeri~di~sequenza|)}
 \itindend{three~way~handshake}
@@ -133,14 +133,14 @@ l'\textit{acknowledgement} di un segmento FIN.
 
 Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
 le cosiddette \textit{TCP options}, da non confondere con le opzioni dei
-socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}; in questo
+socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}. In questo
 caso infatti si tratta delle opzioni che vengono trasmesse come parte di un
 pacchetto TCP, e non delle funzioni che consentono di impostare i relativi
 valori. Queste opzioni vengono inserite fra l'intestazione ed i dati, e
 servono a comunicare all'altro capo una serie di parametri utili a regolare la
-connessione.  Normalmente vengono usate le seguenti opzioni:
+connessione. Normalmente vengono usate le seguenti opzioni:
 
-\begin{itemize}
+\begin{itemize*}
 \item \textit{MSS option}, con questa opzione ciascun capo della connessione
   annuncia all'altro il massimo ammontare di dati (MMS sta appunto per
   \textit{Maximum Segment Size}, vedi sez.~\ref{sec:tcp_protocol}) che
@@ -161,9 +161,9 @@ connessione.  Normalmente vengono usate le seguenti opzioni:
   poter ottenere il massimo dalla trasmissione.
 
   Per questo esiste un'altra opzione che indica un fattore di scala da
-  applicare al valore della finestra annunciata per la connessione corrente
-  (espresso come numero di bit cui spostare a sinistra il valore della
-  finestra annunciata inserito nel pacchetto). Essendo una nuova opzione per
+  applicare al valore della finestra annunciata per la connessione corrente
+  espresso come numero di bit cui spostare a sinistra il valore della
+  finestra annunciata inserito nel pacchetto. Essendo una nuova opzione per
   garantire la compatibilità con delle vecchie realizzazione del protocollo la
   procedura che la attiva prevede come negoziazione che l'altro capo della
   connessione riconosca esplicitamente l'opzione inserendola anche lui nel suo
@@ -182,8 +182,7 @@ connessione.  Normalmente vengono usate le seguenti opzioni:
   per le connessioni ad alta velocità per evitare possibili corruzioni di dati
   dovute a pacchetti perduti che riappaiono; anche questa viene negoziata
   all'inizio della connessione come la precedente.
-
-\end{itemize}
+\end{itemize*}
 
 La \textit{MSS option} è generalmente supportata da quasi tutte le
 realizzazioni del protocollo, le ultime due opzioni (trattate
@@ -201,7 +200,7 @@ Mentre per la creazione di una connessione occorre un interscambio di tre
 segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
 caso la successione degli eventi è la seguente:
 
-\begin{enumerate}
+\begin{enumerate*}
 \item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
   l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
   \textit{active close}). Questo comporta l'emissione di un segmento FIN, che
@@ -221,7 +220,7 @@ caso la successione degli eventi è la seguente:
 
 \item L'altro capo della connessione riceverà il segmento FIN conclusivo e
   risponderà con un ACK.
-\end{enumerate}
+\end{enumerate*}
 
 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
 normalmente i segmenti scambiati sono quattro.  Questo non è vero sempre
@@ -364,18 +363,17 @@ della connessione. Il tempo in cui l'applicazione resta in questo stato deve
 essere due volte la \textit{Maximum Segment Lifetime} (da qui in avanti
 abbreviata in MSL).
 
-La MSL è la stima del massimo periodo di tempo in secondi che un pacchetto IP
-può vivere sulla rete. Questo tempo è limitato perché ogni pacchetto IP può
-essere ritrasmesso dai router un numero massimo di volte (detto \textit{hop
-  limit}).  Il numero di ritrasmissioni consentito è indicato dal campo TTL
-dell'intestazione di IP (per maggiori dettagli vedi
+La \textit{Maximum Segment Lifetime} è la stima del massimo periodo di tempo
+in secondi che un pacchetto IP può vivere sulla rete. Questo tempo è limitato
+perché ogni pacchetto IP può essere ritrasmesso dai router un numero massimo
+di volte (detto \textit{hop limit}).  Il numero di ritrasmissioni consentito è
+indicato dal campo TTL dell'intestazione di IP (per maggiori dettagli vedi
 sez.~\ref{sec:ip_protocol}), e viene decrementato ad ogni passaggio da un
 router; quando si annulla il pacchetto viene scartato.  Siccome il numero è ad
 8 bit il numero massimo di ``\textsl{salti}'' è di 255, pertanto anche se il
 TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
 sua base si può stimare che un pacchetto IP non possa restare nella rete per
-più un certo numero di secondi, che costituisce la \textit{Maximum Segment
-  Lifetime}.
+più un certo numero di secondi, che costituisce la MSL.
 
 Ogni realizzazione del TCP deve scegliere un valore per la MSL;
 l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
@@ -448,10 +446,11 @@ connessione che riappaiono nella nuova.
 
 Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
 creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
-per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
-tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
-nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
-sicuri che lo stesso avvenga per le risposte nella direzione opposta.
+per un periodo di 2 volte la MSL, prima per attendere MSL secondi per essere
+sicuri che tutti i pacchetti duplicati in arrivo siano stati ricevuti e
+scartati, o che nel frattempo siano stati eliminati dalla rete, poi altri MSL
+secondi per essere sicuri che lo stesso avvenga per le risposte nella
+direzione opposta.
 
 In questo modo, prima che venga creata una nuova connessione, il protocollo
 TCP si assicura che tutti gli eventuali segmenti residui di una precedente
@@ -562,10 +561,6 @@ questo caso non abbia senso parlare di connessione. L'utilizzo del programma
 \cmd{netstat} permette di visualizzare queste informazioni nei campi
 \textit{Local Address} e \textit{Foreing Address}.
 
-
-\subsection{Le porte ed il modello client/server}
-\label{sec:TCP_port_cliserv}
-
 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
 che fare con un'applicazione client/server (come quelle che descriveremo in
 sez.~\ref{sec:TCP_daytime_application} e sez.~\ref{sec:TCP_echo_application})
@@ -666,7 +661,9 @@ primo figlio e quelli che arrivano alla porta 21101 al secondo.
 In questa sezione descriveremo in maggior dettaglio le varie funzioni che
 vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
 funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
-precedente in sez.~\ref{sec:sock_creation}.
+precedente in sez.~\ref{sec:sock_creation}. Pur trattandole principalmente dal
+punto di vista dei socket TCP, daremo brevemente conto del loro comportamento
+anche per altri tipi di socket.
 
 
 \subsection{La funzione \func{bind}}
@@ -694,18 +691,23 @@ seguente:
   \begin{errlist}
   \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
     sufficienti privilegi.
-  \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
+  \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo
+    richiesto oppure quando non si è richiesta un porta specifica per avere
+    una porta effimera non ve ne sono di disponibili nell'intervallo ad esse
+    riservato correntemente in uso.
   \item[\errcode{EBADF}] il file descriptor non è valido.
-  \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
+  \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato,
+    o \param{addrlen} è sbagliata, o \param{serv\_addr} non è valido per il
+    dominio.
   \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
   \end{errlist}
-  ed \errval{EFAULT} nel suo significato generico, inoltre per i socket di
+  ed \errval{EFAULT} nel suo significato generico; inoltre per i socket di
   tipo \const{AF\_UNIX}:
   \begin{errlist}
   \item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
     disponibile.
   \end{errlist}
-  ed \errval{ELOOP}, \errval{ENAMETOOLONG},  \errval{ENOENT}, \errval{ENOMEM}, 
+  ed \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, 
   \errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.}
 \end{funcproto}
 
@@ -794,14 +796,13 @@ staticamente a \constd{IN6ADRR\_LOOPBACK\_INIT}.
 \label{sec:TCP_func_connect}
 
 La funzione \funcd{connect} è usata da un client TCP per stabilire la
-connessione con un server TCP,\footnote{di nuovo la funzione è generica e
-  supporta vari tipi di socket, la differenza è che per socket senza
-  connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si
-  limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
-  e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
-  \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
-  TCP il \textit{three way handshake}) della connessione.}  il prototipo della
-funzione è il seguente:
+connessione con un server TCP, ma la funzione è generica e supporta vari tipi
+di socket.  La differenza è che per socket senza connessione come quelli di
+tipo \const{SOCK\_DGRAM} la sua chiamata si limiterà ad impostare l'indirizzo
+dal quale e verso il quale saranno inviati e ricevuti i pacchetti, mentre per
+socket di tipo \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET} essa attiverà
+la procedura di avvio della connessione (nel caso del TCP il \textit{three way
+  handshake}). Il suo prototipo è il seguente:
 
 
 \begin{funcproto}{