X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=5af4f66259967f04ceb680c55a227e08fcd8680e;hp=bbd2e7660399fab4d27c2368b117685a2bd15a34;hb=b02540b05b22d92851c3bae5cce8546601300ee3;hpb=f3bb4dd6dfe5a8d568dca64c56c870508090c168

diff --git a/othersock.tex b/othersock.tex
index bbd2e76..5af4f66 100644
--- a/othersock.tex
+++ b/othersock.tex
@@ -449,13 +449,13 @@ inviati dai client. Lo scopo della funzione 
 volte che un pacchetto viene inviato al server, in modo da poter ricavare da
 esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
 questo motivo in questo caso (al contrario di quanto fatto in
-\figref{fig:UDP_daytime_client}) si è avuto cura di passare gli opportuni
-argomenti alla funzione.  Dopo aver controllato (\texttt{\small 27--30}) la
-presenza di eventuali errori (uscendo con un messaggio di errore qualora ve ne
-siano) si verifica (\texttt{\small 31}) se è stata attivata l'opzione
-\texttt{-v} (che imposta la variabile \var{verbose}) stampando nel caso
-(\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una richiesta
-(questa sezione è identica a quella del server TCP illustrato in
+\figref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
+\var{addr} e \var{len} alla funzione.  Dopo aver controllato (\texttt{\small
+  27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
+qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
+l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
+caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
+richiesta (questa sezione è identica a quella del server TCP illustrato in
 \figref{fig:TCP_daytime_cunc_server_code}).
 
 Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
@@ -471,9 +471,10 @@ fatto che non esiste il concetto di connessione, per cui non c'
 di trattare separatamente le singole connessioni. Questo significa anche che è
 il kernel a gestire la possibilità di richieste multiple in contemporanea;
 quello che succede è semplicemente che il kernel accumula in un buffer in
-ingresso i pacchetti che arrivano e li restituisce al processo uno alla volta
-per ciascuna chiamata di \func{recvfrom}; è poi compito del server distribuire
-le risposte sulla base dell'indirizzo da cui provengono le richieste.
+ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
+volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
+compito del server distribuire le risposte sulla base dell'indirizzo da cui
+provengono le richieste.
 
 
 
@@ -483,7 +484,7 @@ le risposte sulla base dell'indirizzo da cui provengono le richieste.
 
 Come illustrato in \secref{sec:UDP_characteristics} essendo i socket UDP privi
 di connessione non è necessario per i client usare \func{connect} prima di
-iniziare una comunicazione con un server.
+iniziare una comunicazione con un server.