Integrazioni su write

[gapil.git] / othersock.tex

diff --git a/othersock.tex b/othersock.tex
index de8c3d19cfe452736fb1e04fff7c22fbfb0d2293..bffd4aeb1eb1b685c97bdac60eca1f6b29033282 100644 (file)
--- a/othersock.tex
+++ b/othersock.tex
@@ -114,13 +114,23 @@ destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
 \label{sec:UDP_sendto_recvfrom}
 
 Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni
 \label{sec:UDP_sendto_recvfrom}
 
 Come accennato in sez.~\ref{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 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 chiamata ad \func{accept} che lo associa ad una connessione) quali sono
-sorgente e destinazione dei dati.
+principali usate per la trasmissione di dati attraverso i socket UDP (ed in
+generale per i socket di tipo \textit{datagram}) 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 può stabilire (come
+avviene con i socket TCP grazie alla chiamata ad \func{accept} che li associa
+ad una connessione) quali sono la sorgente e la destinazione dei dati che
+passano sul socket.\footnote{anche se in alcuni casi, come quello di un client
+  che contatta un server, è possibile connettere il socket (vedi
+  sez.~\ref{sec:UDP_connect}), la necessità di \func{sendto} e \func{recvfrom}
+  resta, dato che questo è possibile solo sul lato del client.}
+
+Per questo anche se in generale si possono comunque leggere i dati con
+\func{read}, usando questa funzione non si sarà in grado di determinare da
+quale fra i possibili corrispondenti (se ve ne sono più di uno, come avviene
+sul lato del server) questi arrivino. E non sarà comunque possibile usare
+\func{write} (che fallisce un errore di \errval{EDESTADDRREQ}) in quanto non
+è determinato la destinazione che i dati avrebbero.

 
 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 funzioni, che sono comunque utilizzabili in generale per la trasmissione di
 
 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 funzioni, che sono comunque utilizzabili in generale per la trasmissione di


@@ -673,10 +683,12 @@ scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
 qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
 più necessario usare l'argomento \param{to} di \func{sendto} per specificare
 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
 qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
 più necessario usare l'argomento \param{to} di \func{sendto} per specificare
 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando

-le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
-  anche continuare ad usare la funzione \func{sendto}, ma in tal caso
+le normali funzioni \func{read} e \func{write} che a questo punto non
+falliranno più con l'errore di \errval{EDESTADDRREQ}.\footnote{in realtà si
+  può anche continuare ad usare la funzione \func{sendto}, ma in tal caso

   l'argomento \param{to} deve essere inizializzato a \val{NULL}, e
   l'argomento \param{to} deve essere inizializzato a \val{NULL}, e

-  \param{tolen} deve essere inizializzato a zero, pena un errore.}
+  \param{tolen} deve essere inizializzato a zero, pena un errore di
+  \errval{EISCONN}.}

 
 Una volta che il socket è connesso cambia però anche il comportamento in
 ricezione; prima infatti il kernel avrebbe restituito al socket qualunque
 
 Una volta che il socket è connesso cambia però anche il comportamento in
 ricezione; prima infatti il kernel avrebbe restituito al socket qualunque