Usato geometry per le dimensioni della pagina, e completati i commenti

riguardo revcfrom e sendto

diff --git a/gapil.tex b/gapil.tex
index dde18bf1eeb22de3c55ac583a941df89582f4bc4..1d15abe5a60638ead221d04f8f66de1e5cda8dc2 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -42,6 +42,7 @@
 \usepackage{multirow}
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 
 \usepackage{multirow}
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 

+\usepackage{geometry}

 
 \def\tild{\char'176}
 
 
 \def\tild{\char'176}
 


@@ -49,11 +50,14 @@
 %
 % Setting page layout
 %
 %
 % Setting page layout
 %

-\oddsidemargin=0.5cm
-\evensidemargin=-0.5cm
-\textwidth=16cm
-\textheight=24.2cm
-\topmargin=-1.cm
+%\oddsidemargin=0.5cm
+%\evensidemargin=-0.5cm
+%\textwidth=16cm
+%\textheight=24.2cm
+%\topmargin=-1.cm
+\geometry{textheight=24.2cm,textwidth=16cm}
+
+

 %\setcaptionmargin{2cm} 
 %\renewcommand{\chaptername}{Capitolo}
 %\renewcommand{\contentsname}{Indice}
 %\setcaptionmargin{2cm} 
 %\renewcommand{\chaptername}{Capitolo}
 %\renewcommand{\contentsname}{Indice}

diff --git a/othersock.tex b/othersock.tex
index c5195dfe6e66cffecf001b92926abf6c098ddd08..5554e75ebd071a509b2e601ced79f91bdcf7d4f0 100644 (file)
--- a/othersock.tex
+++ b/othersock.tex
@@ -8,19 +8,20 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%

-\chapter{Gli altri socket più comuni}
+\chapter{Gli altri tipi di socket}

 \label{cha:other_socket}
 
 Dopo aver trattato in \capref{cha:TCP_socket} i socket TCP, che costituiscono
 l'esempio più comune dell'interfaccia dei socket, esamineremo in questo
 \label{cha:other_socket}
 
 Dopo aver trattato in \capref{cha:TCP_socket} i socket TCP, che costituiscono
 l'esempio più comune dell'interfaccia dei socket, esamineremo in questo

-capitolo gli altri tipi di socket, 
+capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket deiit
+\textit{Unix domain} già incontrati in \secref{sec:ipc_socketpair}.

 
 
 \section{I socket UDP}
 \label{sec:UDP_socket}
 
 Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
 
 
 \section{I socket UDP}
 \label{sec:UDP_socket}
 
 Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i

-socket UDP; protocolli diffusi come NFS o il DNS usano principalmente questo
+socket UDP: protocolli diffusi come NFS o il DNS usano principalmente questo

 tipo di socket. Tratteremo in questa sezione le loro caratteristiche
 principali e le modalità per il loro utilizzo.
 
 tipo di socket. Tratteremo in questa sezione le loro caratteristiche
 principali e le modalità per il loro utilizzo.
 


@@ -102,8 +103,8 @@ porta 67).
 
 Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
 socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico
 
 Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
 socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico

-non si avranno indicazioni delle connessioni attive, proprio perché non esiste
-niente di simile per i socket UDP, il kernel si limita infatti a ricevere i
+non si avranno indicazioni delle connessioni attive, proprio perché questo
+concetto non esiste per i socket UDP, il kernel si limita infatti a ricevere i

 pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
 destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
   unreachable} qualora non vi sia nessun processo in ascolto.
 pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
 destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
   unreachable} qualora non vi sia nessun processo in ascolto.


@@ -113,8 +114,8 @@ destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
 \label{sec:UDP_sendto_recvfrom}
 
 Come accennato in \secref{sec:UDP_characteristics} le due funzioni principali
 \label{sec:UDP_sendto_recvfrom}
 
 Come accennato in \secref{sec:UDP_characteristics} le due funzioni principali

-usate per la trasmissione di dati attraverso i socket UDP, sono \func{sendto}
-e \func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che
+usate per la trasmissione di dati attraverso i socket UDP sono \func{sendto} e
+\func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che

 non esistendo con UDP il concetto di connessione, non si ha neanche a
 disposizione un \textsl{socket connesso} su cui sia possibile usare
 direttamente \func{read} e \func{write} avendo già stabilito (grazie alla
 non esistendo con UDP il concetto di connessione, non si ha neanche a
 disposizione un \textsl{socket connesso} su cui sia possibile usare
 direttamente \func{read} e \func{write} avendo già stabilito (grazie alla


@@ -123,16 +124,17 @@ sorgente e destinazione dei dati.
 
 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 funzioni, che sono comunque usabili in generale per la trasmissione di dati
 
 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 funzioni, che sono comunque usabili in generale per la trasmissione di dati

-attraverso qualunque tipo di socket, dato che esse hanno la caratteristica di
-provvedere tre argomenti aggiuntivi che consentono di specificare destinazione
-o origine dei dati trasmessi. La prima delle due funzioni è \funcd{sendto} ed
-il suo prototipo\footnote{il prototipo illustrato è quello utilizzato dalle
-  \acr{glibc}, che seguono le \textit{Single Unix Specification}, l'argomento
-  \param{flags} era di tipo \type{int} nei vari BSD4.*, mentre nelle
-  \acr{libc4} e \acr{libc5} veniva usato un \type{unsigned int}; l'argomento
-  \param{len} era \type{int} nei vari BSD4.* e nelle \acr{libc4}, ma
-  \type{size\_t} nelle \acr{libc5}; infine l'argomento \param{tolen} era
-  \type{int} nei vari BSD4.* nelle \acr{libc4} e nelle \acr{libc5}.} è:
+attraverso qualunque tipo di socket. Esse hanno la caratteristica di prevedere
+tre argomenti aggiuntivi attraveso i quali è possibile specificare la
+destinazione o l'origine dei dati trasmessi. La prima di queste funzioni è
+\funcd{sendto} ed il suo prototipo\footnote{il prototipo illustrato è quello
+  utilizzato dalle \acr{glibc}, che seguono le \textit{Single Unix
+    Specification}, l'argomento \param{flags} era di tipo \type{int} nei vari
+  BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva usato un
+  \type{unsigned int}; l'argomento \param{len} era \type{int} nei vari BSD4.*
+  e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine l'argomento
+  \param{tolen} era \type{int} nei vari BSD4.* nelle \acr{libc4} e nelle
+  \acr{libc5}.} è:

 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}


@@ -187,8 +189,8 @@ il messaggio all'interno di un unico pacchetto essa fallisce con l'errore di
 I due argomenti \param{to} e \param{tolen} servono a specificare la
 destinazione del messaggio da inviare, e prendono l'indirizzo di quest'ultima,
 nella stessa forma in cui lo si specificherebbe per \func{connect}: \param{to}
 I due argomenti \param{to} e \param{tolen} servono a specificare la
 destinazione del messaggio da inviare, e prendono l'indirizzo di quest'ultima,
 nella stessa forma in cui lo si specificherebbe per \func{connect}: \param{to}

-deve cioè contere l'indirizzo IP e la porta di destinazione cui si vogliono
-inviare i dati e \param{tolen} la relativa dimensione. 
+deve cioè contenere l'indirizzo IP e la porta di destinazione cui si vogliono
+inviare i dati e \param{tolen} la relativa dimensione.

 
 Se il socket è di un tipo che prevede le connessioni, questo deve essere già
 connesso prima di eseguire la funzione (altrimenti si avrà un errore di
 
 Se il socket è di un tipo che prevede le connessioni, questo deve essere già
 connesso prima di eseguire la funzione (altrimenti si avrà un errore di


@@ -242,11 +244,39 @@ Come per \func{sendto} i primi tre argomenti sono identici agli analoghi di
 \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel
 buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
 o \textit{stream}) inoltre i byte in eccesso che non sono stati letti possono
 \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel
 buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
 o \textit{stream}) inoltre i byte in eccesso che non sono stati letti possono

-rispettivamente andare persi o restare disponibili per una lettura
-successiva. Se non sono disponibili dati la funzione si blocca, a meno di non
-aver aperto il socket in modalità non bloccante, nel qual caso si avrà il
-solito errore di \errcode{EAGAIN}.
-
+rispettivamente andare persi o restare disponibili per una lettura successiva.
+Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
+il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
+\errcode{EAGAIN}.  Qualora \param{len} ecceda la dimensione del pacchetto la
+funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
+comunque il numero di byte letti.
+
+I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
+l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
+opportunamente inizializzati con i puntatori alle variabili dove quest'ultimo
+e la sua lunghezza saranno memorizzati (si noti che \param{fromlen} è un
+valore intero ottenuto come \textit{value return argoment}).  Se non si è
+interessati a questa informazione, entrambi gli argomenti devono essere
+inizializzati al valore \const{NULL}.
+
+Un'altra differenza fondamentale di queste funzioni rispetto alle usuali
+\func{read} e \func{write} che abbiamo usato con i socket TCP è che in questo
+caso è perfettamente legale inviare con \func{sendto} un pacchetto vuoto (che
+nel caso conterrà solo le intestazioni di IP e di UDP), scrivendo 0 byte. Allo
+stesso è possibile ricevere con \func{recvfrom} un valore di ritorno di 0
+byte, senza che questo possa configurarsi come una chiusura della
+connessione\footnote{dato che la connessione non esiste, non ha senso parlare
+  di chiusura della connessione, pertanto con i socket UDP non è necessario
+  usare \func{close} per terminare la cominicazione.} o come una cessazione
+delle comunicazioni.
+
+
+\subsection{Un client elementare}
+\label{sec:UDP_simple_server}
+
+Vediamo allora come implementare un primo server elementare su UDP; ricalcando
+quanto fatto nel caso dei socket TCP prenderemo come primo esempio l'uso del
+servizio \textit{time}, utilizzanto questa volta UDP.