othersock.tex

   1 %% othersock.tex
   2 %%
   3 %% Copyright (C) 2004-2015 Simone Piccardi.  Permission is granted to
   4 %% copy, distribute and/or modify this document under the terms of the GNU Free
   5 %% Documentation License, Version 1.1 or any later version published by the
   6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
   7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
   8 %% license is included in the section entitled "GNU Free Documentation
   9 %% License".
  10 %%
  11
  12 \chapter{Gli altri tipi di socket}
  13 \label{cha:other_socket}
  14
  15 Dopo aver trattato in cap.~\ref{cha:TCP_socket} i socket TCP, che
  16 costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
  17 questo capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
  18 \textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
  19
  20
  21 \section{I socket UDP}
  22 \label{sec:UDP_socket}
  23
  24 Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
  25 socket UDP: protocolli diffusi come NFS o il DNS usano principalmente questo
  26 tipo di socket. Tratteremo in questa sezione le loro caratteristiche
  27 principali e le modalità per il loro utilizzo.
  28
  29
  30 \subsection{Le caratteristiche di un socket UDP}
  31 \label{sec:UDP_characteristics}
  32
  33 Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che
  34 non supporta le connessioni e non è affidabile: esso si appoggia direttamente
  35 sopra IP (per i dettagli sul protocollo si veda sez.~\ref{sec:udp_protocol}).
  36 I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
  37 effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
  38 vantaggio del protocollo è la velocità, non è necessario trasmettere le
  39 informazioni di controllo ed il risultato è una trasmissione di dati più
  40 veloce ed immediata.
  41
  42 Questo significa che a differenza dei socket TCP i socket UDP non supportano
  43 una comunicazione di tipo \textit{stream} in cui si ha a disposizione un
  44 flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
  45 una comunicazione di tipo \textit{datagram}, in cui i dati arrivano in singoli
  46 blocchi che devono essere letti integralmente.
  47
  48 Questo diverso comportamento significa anche che i socket UDP, pur
  49 appartenendo alla famiglia \const{PF\_INET}\footnote{o \const{PF\_INET6}
  50   qualora si usasse invece il protocollo IPv6, che pure supporta UDP.} devono
  51 essere aperti quando si usa la funzione \func{socket} (si riveda quanto
  52 illustrato a suo tempo in tab.~\ref{tab:sock_sock_valid_combinations})
  53 utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
  54
  55 Questa differenza comporta ovviamente che anche le modalità con cui si usano i
  56 socket UDP sono completamente diverse rispetto ai socket TCP, ed in
  57 particolare non esistendo il concetto di connessione non esiste il meccanismo
  58 del \itindex{three~way~handshake} \textit{three way handshake} né quello degli
  59 stati del protocollo. In realtà tutto quello che avviene nella comunicazione
  60 attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un
  61 server o viceversa, secondo lo schema illustrato in
  62 fig.~\ref{fig:UDP_packet-exchange}.
  63
  64 \begin{figure}[!htb]
  65   \centering \includegraphics[width=10cm]{img/udp_connection}
  66   \caption{Lo schema di interscambio dei pacchetti per una comunicazione via
  67      UDP.}
  68   \label{fig:UDP_packet-exchange}
  69 \end{figure}
  70
  71 Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
  72 un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
  73 per mettersi in ascolto dei dati, questa è l'unica parte comune con un server
  74 TCP. Non essendovi il concetto di connessione le funzioni \func{listen} ed
  75 \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
  76 dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
  77 eventuale risposta sarà inviata con la funzione \func{sendto}.
  78
  79 Da parte del client invece, una volta creato il socket non sarà necessario
  80 connettersi con \func{connect} (anche se, come vedremo in
  81 sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un
  82 significato comunque diverso) ma si potrà effettuare direttamente una
  83 richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
  84 leggere una eventuale risposta con la funzione \func{recvfrom}.
  85
  86 Anche se UDP è completamente diverso rispetto a TCP resta identica la
  87 possibilità di gestire più canali di comunicazione fra due macchine
  88 utilizzando le porte. In questo caso il server dovrà usare comunque la
  89 funzione \func{bind} per scegliere la porta su cui ricevere i dati, e come nel
  90 caso dei socket TCP si potrà usare il comando \cmd{netstat} per
  91 verificare quali socket sono in ascolto:
  92 \begin{verbatim}
  93 [piccardi@gont gapil]# netstat -anu
  94 Active Internet connections (servers and established)
  95 Proto Recv-Q Send-Q Local Address           Foreign Address         State
  96 udp        0      0 0.0.0.0:32768           0.0.0.0:*
  97 udp        0      0 192.168.1.2:53          0.0.0.0:*
  98 udp        0      0 127.0.0.1:53            0.0.0.0:*
  99 udp        0      0 0.0.0.0:67              0.0.0.0:*
 100 \end{verbatim}
 101 in questo caso abbiamo attivi il DNS (sulla porta 53, e sulla 32768 per la
 102 connessione di controllo del server \cmd{named}) ed un server DHCP (sulla
 103 porta 67).
 104
 105 Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
 106 socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico
 107 non si avranno indicazioni delle connessioni attive, proprio perché questo
 108 concetto non esiste per i socket UDP, il kernel si limita infatti a ricevere i
 109 pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
 110 destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
 111   unreachable} qualora non vi sia nessun processo in ascolto.
 112
 113
 114 \subsection{Le funzioni \func{sendto} e \func{recvfrom}}
 115 \label{sec:UDP_sendto_recvfrom}
 116
 117 Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni
 118 principali usate per la trasmissione di dati attraverso i socket UDP sono
 119 \func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è
 120 dovuta al fatto che non esistendo con UDP il concetto di connessione, non si
 121 ha neanche a disposizione un \textsl{socket connesso} su cui sia possibile
 122 usare direttamente \func{read} e \func{write} avendo già stabilito (grazie
 123 alla chiamata ad \func{accept} che lo associa ad una connessione) quali sono
 124 sorgente e destinazione dei dati.
 125
 126 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 127 funzioni, che sono comunque utilizzabili in generale per la trasmissione di
 128 dati attraverso qualunque tipo di socket. Esse hanno la caratteristica di
 129 prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
 130 la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
 131 prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
 132   prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
 133   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
 134   \ctyp{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
 135   usato un \texttt{unsigned int}; l'argomento \param{len} era \ctyp{int} nei
 136   vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5};
 137   infine l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.* nelle
 138   \acr{libc4} e nelle \acr{libc5}.} è:
 139 \begin{functions}
 140   \headdecl{sys/types.h}
 141   \headdecl{sys/socket.h}
 142
 143   \funcdecl{ssize\_t sendto(int sockfd, const void *buf, size\_t len, int
 144     flags, const struct sockaddr *to, socklen\_t tolen)}
 145
 146   Trasmette un messaggio ad un altro socket.
 147
 148   \bodydesc{La funzione restituisce il numero di caratteri inviati in caso di
 149     successo e -1 per un errore; nel qual caso \var{errno} viene impostata al
 150     rispettivo codice di errore:
 151   \begin{errlist}
 152   \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
 153     l'operazione richiede che la funzione si blocchi.
 154   \item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la
 155     connessione.
 156   \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
 157     specificato un indirizzo di destinazione.
 158   \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
 159     destinatario.
 160   \item[\errcode{EMSGSIZE}] il tipo di socket richiede l'invio dei dati in un
 161     blocco unico, ma la dimensione del messaggio lo rende impossibile.
 162   \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
 163     norma Linux non usa questo messaggio ma scarta silenziosamente i
 164     pacchetti).
 165   \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
 166     una destinazione.
 167   \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
 168     il tipo di socket usato.
 169   \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
 170     riceverà anche un segnale di \signal{SIGPIPE}, a meno di non aver impostato
 171     \const{MSG\_NOSIGNAL} in \param{flags}.
 172   \end{errlist}
 173   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
 174   \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
 175   ai protocolli utilizzati.}
 176 \end{functions}
 177
 178 I primi tre argomenti sono identici a quelli della funzione \func{write} e
 179 specificano il socket \param{sockfd} a cui si fa riferimento, il buffer
 180 \param{buf} che contiene i dati da inviare e la relativa lunghezza
 181 \param{len}.  Come per \func{write} la funzione ritorna il numero di byte
 182 inviati; nel caso di UDP però questo deve sempre corrispondere alla dimensione
 183 totale specificata da \param{len} in quanto i dati vengono sempre inviati in
 184 forma di pacchetto e non possono essere spezzati in invii successivi.  Qualora
 185 non ci sia spazio nel buffer di uscita la funzione si blocca (a meno di non
 186 avere aperto il socket in modalità non bloccante), se invece non è possibile
 187 inviare il messaggio all'interno di un unico pacchetto (ad esempio perché
 188 eccede le dimensioni massime del protocollo sottostante utilizzato) essa
 189 fallisce con l'errore di \errcode{EMSGSIZE}.
 190
 191 I due argomenti \param{to} e \param{tolen} servono a specificare la
 192 destinazione del messaggio da inviare, e indicano rispettivamente la struttura
 193 contenente l'indirizzo di quest'ultima e la sua dimensione; questi argomenti
 194 vanno specificati stessa forma in cui li si sarebbero usati con
 195 \func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura
 196 contenente l'indirizzo IP e la porta di destinazione verso cui si vogliono
 197 inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando
 198 socket diversi si sarebbero dovute utilizzare le rispettive strutture degli
 199 indirizzi).
 200
 201 Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
 202 TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
 203 caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
 204 specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono
 205 essi dovranno essere inizializzati rispettivamente a \val{NULL} e 0;
 206 normalmente quando si opera su un socket connesso essi vengono ignorati, ma
 207 qualora si sia specificato un indirizzo è possibile ricevere un errore di
 208 \errcode{EISCONN}.
 209
 210 Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
 211 come maschera binaria che permette di impostare una serie di modalità di
 212 funzionamento della comunicazione attraverso il socket (come
 213 \const{MSG\_NOSIGNAL} che impedisce l'invio del segnale \signal{SIGPIPE} quando
 214 si è già chiuso il capo locale della connessione). Torneremo con maggiori
 215 dettagli sul significato di questo argomento in sez.~\ref{sec:net_sendmsg},
 216 dove tratteremo le funzioni avanzate dei socket, per il momento ci si può
 217 limitare ad usare sempre un valore nullo.
 218
 219 La seconda funzione utilizzata nella comunicazione fra socket UDP è
 220 \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
 221 suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
 222   \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le
 223   \acr{libc5} usano un \ctyp{int} come valore di ritorno; per gli argomenti
 224   \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
 225   infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, le
 226   \acr{libc4} e le \acr{libc5}.} è:
 227 \begin{functions}
 228   \headdecl{sys/types.h}
 229   \headdecl{sys/socket.h}
 230
 231   \funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
 232     flags, const struct sockaddr *from, socklen\_t *fromlen)}
 233
 234   Riceve un messaggio da un socket.
 235
 236   \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
 237     successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
 238     valore:
 239   \begin{errlist}
 240   \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
 241     l'operazione richiede che la funzione si blocchi, oppure si è impostato un
 242     timeout in ricezione e questo è scaduto.
 243   \item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato
 244     la connessione (in genere perché il relativo servizio non è disponibile).
 245   \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
 246     la connessione.
 247   \end{errlist}
 248   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
 249   \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
 250   ai protocolli utilizzati.}
 251 \end{functions}
 252
 253 Come per \func{sendto} i primi tre argomenti sono identici agli analoghi di
 254 \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel
 255 buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
 256 o di tipo \textit{stream}) i byte in eccesso che non sono stati letti possono
 257 rispettivamente andare persi o restare disponibili per una lettura successiva.
 258 Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
 259 il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
 260 \errcode{EAGAIN}.  Qualora \param{len} ecceda la dimensione del pacchetto la
 261 funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
 262 comunque il numero di byte letti.
 263
 264 I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
 265 l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
 266 opportunamente inizializzati; il primo deve contenere il puntatore alla
 267 struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
 268 puntatore alla variabile con la dimensione di detta struttura. Si tenga
 269 presente che mentre il contenuto della struttura \ctyp{sockaddr} cui punta
 270 \param{from} può essere qualunque, la variabile puntata da \param{fromlen}
 271 deve essere opportunamente inizializzata a \code{sizeof(sockaddr)},
 272 assicurandosi che la dimensione sia sufficiente a contenere tutti i dati
 273 dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
 274   serve ad indicare la struttura corrispondente allo specifico tipo di
 275   indirizzo richiesto, il valore di \param{fromlen} pone un limite alla
 276   quantità di dati che verranno scritti sulla struttura puntata da
 277   \param{from} e se è insufficiente l'indirizzo risulterà corrotto.}  Al
 278 ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
 279 lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
 280 \textit{value result argument}).  Se non si è interessati a questa
 281 informazione, entrambi gli argomenti devono essere inizializzati al valore
 282 \val{NULL}.
 283
 284 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
 285 usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
 286 questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
 287 vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
 288 specificando un valore nullo per \param{len}. Allo stesso modo è possibile
 289 ricevere con \func{recvfrom} un valore di ritorno di 0 byte, senza che questo
 290 possa configurarsi come una chiusura della connessione\footnote{dato che la
 291   connessione non esiste, non ha senso parlare di chiusura della connessione,
 292   questo significa anche che con i socket UDP non è necessario usare
 293   \func{close} o \func{shutdown} per terminare la comunicazione.} o come una
 294 cessazione delle comunicazioni.
 295
 296
 297
 298 \subsection{Un client UDP elementare}
 299 \label{sec:UDP_daytime_client}
 300
 301 Vediamo allora come implementare un primo client elementare con dei socket
 302 UDP.  Ricalcando quanto fatto nel caso dei socket TCP prenderemo come primo
 303 esempio l'uso del servizio \textit{daytime}, utilizzando questa volta UDP. Il
 304 servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
 305 che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
 306 UDP al server (di contenuto non specificato), il quale risponderà a inviando a
 307 sua volta un pacchetto UDP contenente la data.
 308
 309 \begin{figure}[!htbp]
 310   \footnotesize \centering
 311   \begin{minipage}[c]{\codesamplewidth}
 312     \includecodesample{listati/UDP_daytime.c}
 313   \end{minipage}
 314   \normalsize
 315   \caption{Sezione principale del client per il servizio \textit{daytime} su
 316     UDP.}
 317   \label{fig:UDP_daytime_client}
 318 \end{figure}
 319
 320 In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
 321 codice del nostro client, il sorgente completo si trova nel file
 322 \file{UDP\_daytime.c} distribuito con gli esempi allegati alla guida; al
 323 solito si è tralasciato di riportare in figura la sezione relativa alla
 324 gestione delle opzioni a riga di comando (nel caso praticamente assenti).
 325
 326 Il programma inizia (\texttt{\small 9--12}) con la creazione del socket, al
 327 solito uscendo dopo aver stampato un messaggio in caso errore. Si noti come in
 328 questo caso, rispetto all'analogo client basato su socket TCP di
 329 fig.~\ref{fig:TCP_daytime_client_code} si sia usato per il tipo di socket il
 330 valore \const{SOCK\_DGRAM}, pur mantenendosi nella stessa famiglia data da
 331 \const{AF\_INET}.
 332
 333 Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
 334 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
 335 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
 336 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
 337 (\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare
 338 dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
 339 Si noti come questa sezione sia identica a quella del client TCP di
 340 fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
 341 di UDP al posto di TCP è stata effettuata quando si è creato il socket.
 342
 343 Una volta completate le inizializzazioni inizia il corpo principale del
 344 programma, il primo passo è inviare, come richiesto dal protocollo, un
 345 pacchetto al server. Questo lo si fa (\texttt{\small 16}) inviando un
 346 pacchetto vuoto (si ricordi quanto detto in
 347 sez.~\ref{sec:UDP_sendto_recvfrom}) con \func{sendto}, avendo cura di passare
 348 un valore nullo per il puntatore al buffer e la lunghezza del messaggio. In
 349 realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
 350 server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
 351
 352 Verificato (\texttt{\small 24--27}) che non ci siano stati errori nell'invio
 353 si provvede (\texttt{\small 28}) ad invocare \func{recvfrom} per ricevere la
 354 risposta del server. Si controlla poi (\texttt{\small 29--32}) che non vi
 355 siano stati errori in ricezione (uscendo con un messaggio in caso contrario);
 356 se è tutto a posto la variabile \var{nread} conterrà la dimensione del
 357 messaggio di risposta inviato dal server che è stato memorizzato su
 358 \var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
 359 provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
 360 lettura\footnote{si ricordi che, come illustrato in
 361   sez.~\ref{sec:TCP_daytime_client}, il server invia in risposta una stringa
 362   contenente la data, terminata dai due caratteri CR e LF, che pertanto prima
 363   di essere stampata deve essere opportunamente terminata con un NUL.} e a
 364 stamparla (\texttt{\small 36}) sullo standard output, controllando anche in
 365 questo caso (\texttt{\small 36--38}) l'esito dell'operazione, ed uscendo con
 366 un messaggio in caso di errore.
 367
 368 Se pertanto si è avuto cura di attivare il server del servizio
 369 \textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
 370   \textsl{superdemone} \cmd{inetd}, per cui basta abilitarlo nel file di
 371   configurazione di quest'ultimo, avendo cura di predisporre il servizio su
 372   UDP.} potremo verificare il funzionamento del nostro client interrogando
 373 quest'ultimo con:
 374 \begin{verbatim}
 375 [piccardi@gont sources]$ ./daytime 127.0.0.1
 376 Sat Mar 20 23:17:13 2004
 377 \end{verbatim}%$
 378 ed osservando il traffico con uno sniffer potremo effettivamente vedere lo
 379 scambio dei due pacchetti, quello vuoto di richiesta, e la risposta del
 380 server:
 381 \begin{verbatim}
 382 [root@gont gapil]# tcpdump -i lo
 383 tcpdump: listening on lo
 384 23:41:21.645579 localhost.32780 > localhost.daytime: udp 0 (DF)
 385 23:41:21.645710 localhost.daytime > localhost.32780: udp 26 (DF)
 386 \end{verbatim}
 387
 388 Una differenza fondamentale del nostro client è che in questo caso, non
 389 disponendo di una connessione, è per lui impossibile riconoscere errori di
 390 invio relativi alla rete. La funzione \func{sendto} infatti riporta solo
 391 errori locali, i dati vengono comunque scritti e la funzione ritorna senza
 392 errori anche se il server non è raggiungibile o non esiste un server in
 393 ascolto sull'indirizzo di destinazione. Questo comporta ad esempio che se si
 394 usa il nostro programma interrogando un server inesistente questo resterà
 395 perennemente bloccato nella chiamata a \func{recvfrom}, fin quando non lo
 396 interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
 397 a questa problematica.
 398
 399
 400 \subsection{Un server UDP elementare}
 401 \label{sec:UDP_daytime_server}
 402
 403 Nella sezione precedente abbiamo visto come scrivere un client elementare per
 404 servizio \textit{daytime}, vediamo in questa come deve essere scritto un
 405 server.  Si ricordi che il compito di quest'ultimo è quello di ricevere un
 406 pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
 407 stringa con la data corrente.
 408
 409 \begin{figure}[!htbp]
 410   \footnotesize \centering
 411   \begin{minipage}[c]{\codesamplewidth}
 412     \includecodesample{listati/UDP_daytimed.c}
 413   \end{minipage}
 414   \normalsize
 415   \caption{Sezione principale del server per il servizio \textit{daytime} su
 416     UDP.}
 417   \label{fig:UDP_daytime_server}
 418 \end{figure}
 419
 420 In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
 421 codice del nostro client, il sorgente completo si trova nel file
 422 \file{UDP\_daytimed.c} distribuito con gli esempi allegati alla guida; anche
 423 in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
 424 riga di comando (la sola presente è \texttt{-v} che permette di stampare a
 425 video l'indirizzo associato ad ogni richiesta).
 426
 427 Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
 428 sostanzialmente identica a quella dell'analogo server per TCP illustrato in
 429 fig.~\ref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10})
 430 con il creare il socket, uscendo con un messaggio in caso di errore
 431 (\texttt{\small 10--13}), e di nuovo la sola differenza con il caso precedente
 432 è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
 433 si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
 434 usata da \func{bind}; si cancella (\texttt{\small 15}) preventivamente il
 435 contenuto, si imposta (\texttt{\small 16}) la famiglia dell'indirizzo, la
 436 porta (\texttt{\small 17}) e l'indirizzo (\texttt{\small 18}) su cui si
 437 riceveranno i pacchetti.  Si noti come in quest'ultimo sia l'indirizzo
 438 generico \const{INADDR\_ANY}; questo significa (si ricordi quanto illustrato
 439 in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
 440 qualunque degli indirizzi presenti sulle interfacce di rete della macchina.
 441
 442 Completata l'inizializzazione tutto quello che resta da fare è eseguire
 443 (\texttt{\small 20--23}) la chiamata a \func{bind}, controllando la presenza
 444 di eventuali errori, ed uscendo con un avviso qualora questo fosse il caso.
 445 Nel caso di socket UDP questo è tutto quello che serve per consentire al
 446 server di ricevere i pacchetti a lui indirizzati, e non è più necessario
 447 chiamare successivamente \func{listen}. In questo caso infatti non esiste il
 448 concetto di connessione, e quindi non deve essere predisposta una coda delle
 449 connessioni entranti. Nel caso di UDP i pacchetti arrivano al kernel con un
 450 certo indirizzo ed una certa porta di destinazione, il kernel controlla se
 451 corrispondono ad un socket che è stato \textsl{legato} ad essi con
 452 \func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
 453 socket, così che il programma possa leggerlo, altrimenti risponderà alla
 454 macchina che ha inviato il pacchetto con un messaggio ICMP di tipo
 455 \textit{port unreachable}.
 456
 457 Una volta completata la fase di inizializzazione inizia il corpo principale
 458 (\texttt{\small 24--44}) del server, mantenuto all'interno di un ciclo
 459 infinito in cui si trattano le richieste. Il ciclo inizia (\texttt{\small 26})
 460 con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
 461 inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
 462 volte che un pacchetto viene inviato al server, in modo da poter ricavare da
 463 esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
 464 questo motivo in questo caso (al contrario di quanto fatto in
 465 fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
 466 \var{addr} e \var{len} alla funzione.  Dopo aver controllato (\texttt{\small
 467   27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
 468 qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
 469 l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
 470 caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
 471 richiesta (questa sezione è identica a quella del server TCP illustrato in
 472 fig.~\ref{fig:TCP_daytime_cunc_server_code}).
 473
 474 Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
 475 (\texttt{\small 36}) e costruire (\texttt{\small 37}) la stringa di risposta,
 476 che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
 477 avendo al solito cura di controllare (\texttt{\small 40--42}) lo stato di
 478 uscita della funzione e trattando opportunamente la condizione di errore.
 479
 480 Si noti come per le peculiarità del protocollo si sia utilizzato un server
 481 iterativo, che processa le richieste una alla volta via via che gli arrivano.
 482 Questa è una caratteristica comune dei server UDP, conseguenza diretta del
 483 fatto che non esiste il concetto di connessione, per cui non c'è la necessità
 484 di trattare separatamente le singole connessioni. Questo significa anche che è
 485 il kernel a gestire la possibilità di richieste multiple in contemporanea;
 486 quello che succede è semplicemente che il kernel accumula in un buffer in
 487 ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
 488 volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
 489 compito del server distribuire le risposte sulla base dell'indirizzo da cui
 490 provengono le richieste.
 491
 492
 493 \subsection{Le problematiche dei socket UDP}
 494 \label{sec:UDP_problems}
 495
 496 L'esempio del servizio \textit{daytime} illustrato nelle precedenti sezioni
 497 è in realtà piuttosto particolare, e non evidenzia quali possono essere i
 498 problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
 499 connessione che sono tipiche dei socket UDP. In tal caso infatti il protocollo
 500 è estremamente semplice, dato che la comunicazione consiste sempre in una
 501 richiesta seguita da una risposta, per uno scambio di dati effettuabile con un
 502 singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
 503 complessi da rilevare.
 504
 505 Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
 506 la risposta del server si perdono, il client resterà permanentemente bloccato
 507 nella chiamata a \func{recvfrom}. Per evidenziare meglio quali problemi si
 508 possono avere proviamo allora con un servizio leggermente più complesso come
 509 \textit{echo}.
 510
 511 \begin{figure}[!htbp]
 512   \footnotesize \centering
 513   \begin{minipage}[c]{\codesamplewidth}
 514     \includecodesample{listati/UDP_echo_first.c}
 515   \end{minipage}
 516   \normalsize
 517   \caption{Sezione principale della prima versione client per il servizio
 518     \textit{echo} su UDP.}
 519   \label{fig:UDP_echo_client}
 520 \end{figure}
 521
 522 In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
 523 del nostro client elementare per il servizio \textit{echo} (al solito il
 524 codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
 525 client visto in fig.~\ref{fig:TCP_echo_client_1} sono che al solito si crea
 526 (\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
 527 presente nessuna chiamata a \func{connect}. Per il resto il funzionamento del
 528 programma è identico, e tutto il lavoro viene effettuato attraverso la
 529 chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
 530 però prende un argomento in più, che è l'indirizzo del socket.
 531
 532 \begin{figure}[!htbp]
 533   \footnotesize \centering
 534   \begin{minipage}[c]{\codesamplewidth}
 535     \includecodesample{listati/UDP_ClientEcho_first.c}
 536   \end{minipage}
 537   \normalsize
 538   \caption{Codice della funzione \func{ClientEcho} usata dal client per il
 539     servizio \textit{echo} su UDP.}
 540   \label{fig:UDP_echo_client_echo}
 541 \end{figure}
 542
 543 Ovviamente in questo caso il funzionamento della funzione, il cui codice è
 544 riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
 545 rispetto alla analoga del server TCP, e dato che non esiste una connessione
 546 questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
 547 inviare i pacchetti.
 548
 549 Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
 550 più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
 551   6--30}) che parte dalla lettura (\texttt{\small 7}) sul buffer di invio
 552 \var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
 553 (\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
 554 immediatamente causando anche la susseguente terminazione del programma.
 555
 556 Altrimenti si procede (\texttt{\small 10--11}) all'invio della stringa al
 557 destinatario invocando \func{sendto}, utilizzando, oltre alla stringa appena
 558 letta, gli argomenti passati nella chiamata a \func{ClientEcho}, ed in
 559 particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
 560 (\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
 561 (\texttt{\small 13--14}) ad uscire con un messaggio di errore.
 562
 563 Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
 564 leggere l'eventuale risposta del server con \func{recvfrom}; si noti come in
 565 questo caso si sia scelto di ignorare l'indirizzo dell'eventuale pacchetto di
 566 risposta, controllando (\texttt{\small 18--21}) soltanto la presenza di un
 567 errore (nel qual caso al solito si ritorna dopo la stampa di un adeguato
 568 messaggio). Si noti anche come, rispetto all'analoga funzione
 569 \func{ClientEcho} utilizzata nel client TCP illustrato in
 570 sez.~\ref{sec:TCP_echo_client} non si sia controllato il caso di un messaggio
 571 nullo, dato che, nel caso di socket UDP, questo non significa la terminazione
 572 della comunicazione.
 573
 574 L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
 575 stringa di risposta nel relativo buffer per poi provvedere alla sua stampa
 576 sullo standard output, eseguendo il solito controllo (ed eventuale uscita con
 577 adeguato messaggio informativo) in caso di errore.
 578
 579 In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
 580 problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
 581 (nel caso dell'esempio seguente su una VPN, attraverso una ADSL abbastanza
 582 congestionata) e in modalità non interattiva, la probabilità di perdere
 583 qualche pacchetto aumenta, ed infatti, eseguendo il comando come:
 584 \begin{verbatim}
 585 [piccardi@gont sources]$ cat UDP_echo.c | ./echo 192.168.1.120
 586 /* UDP_echo.c
 587  *
 588  * Copyright (C) 2004 Simone Piccardi
 589 ...
 590 ...
 591 /*
 592  * Include needed headers
 593
 594 \end{verbatim}%$
 595 si otterrà che, dopo aver correttamente stampato alcune righe, il programma si
 596 blocca completamente senza stampare più niente. Se al contempo si fosse tenuto
 597 sotto controllo il traffico UDP diretto o proveniente dal servizio
 598 \textit{echo} con \cmd{tcpdump} si sarebbe ottenuto:
 599 \begin{verbatim}
 600 [root@gont gapil]# tcpdump  \( dst port 7 or src port 7 \)
 601 ...
 602 ...
 603 18:48:16.390255 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
 604 18:48:17.177613 192.168.1.120.echo > gont.earthsea.ea.32788: udp 4 (DF)
 605 18:48:17.177790 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 26 (DF)
 606 18:48:17.964917 192.168.1.120.echo > gont.earthsea.ea.32788: udp 26 (DF)
 607 18:48:17.965408 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
 608 \end{verbatim}
 609 che come si vede il traffico fra client e server si interrompe dopo l'invio di
 610 un pacchetto UDP per il quale non si è ricevuto risposta.
 611
 612 Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
 613 una richiesta non arriva a destinazione, il nostro programma si bloccherà
 614 nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
 615 in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
 616 pacchetti, il risultato è diverso, se si lancia al solito il programma e si
 617 prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
 618 se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
 619 \begin{verbatim}
 620 [root@gont gapil]# tcpdump  \( dst 192.168.0.2 and src 192.168.1.120 \) \
 621    or \( src 192.168.0.2 and dst 192.168.1.120 \)
 622 tcpdump: listening on eth0
 623 00:43:27.606944 gont.earthsea.ea.32789 > 192.168.1.120.echo: udp 6 (DF)
 624 00:43:27.990560 192.168.1.120 > gont.earthsea.ea: icmp: 192.168.1.120 udp port
 625 echo unreachable [tos 0xc0]
 626 \end{verbatim}
 627 cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
 628 irraggiungibile che ci segnala che la porta in questione non risponde.
 629
 630 Ci si può chiedere allora perché, benché la situazione di errore sia
 631 rilevabile, questa non venga segnalata. Il luogo più naturale in cui
 632 riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
 633 di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
 634 questo punto però è impossibile, dato che l'interfaccia di programmazione
 635 richiede che la funzione ritorni non appena il kernel invia il
 636 pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
 637   una situazione cioè in cui la condizione di errore viene rilevata in maniera
 638   asincrona rispetto all'operazione che l'ha causata, una eventualità
 639   piuttosto comune quando si ha a che fare con la rete, tutti i pacchetti ICMP
 640   che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
 641 una attesa di una risposta che potrebbe essere molto lunga (si noti infatti
 642 che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
 643 esserci affatto.
 644
 645 Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
 646 comunque bloccata in attesa di una risposta che nel caso non arriverà mai.  La
 647 ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
 648 Stevens in \cite{UNP2} con il seguente esempio: si consideri un client che
 649 invia tre pacchetti a tre diverse macchine, due dei quali vengono regolarmente
 650 ricevuti, mentre al terzo, non essendo presente un server sulla relativa
 651 macchina, viene risposto con un messaggio ICMP come il precedente. Detto
 652 messaggio conterrà anche le informazioni relative ad indirizzo e porta del
 653 pacchetto che ha fallito, però tutto quello che il kernel può restituire al
 654 programma è un codice di errore in \var{errno}, con il quale è impossibile di
 655 distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
 656 stata fatta la scelta di non riportare un errore su un socket UDP, a meno che,
 657 come vedremo in sez.~\ref{sec:UDP_connect}, questo non sia connesso.
 658
 659
 660
 661 \subsection{L'uso della funzione \func{connect} con i socket UDP}
 662 \label{sec:UDP_connect}
 663
 664 Come illustrato in sez.~\ref{sec:UDP_characteristics} essendo i socket UDP
 665 privi di connessione non è necessario per i client usare \func{connect} prima
 666 di iniziare una comunicazione con un server. Ciò non di meno abbiamo accennato
 667 come questa possa essere utilizzata per gestire la presenza di errori
 668 asincroni.
 669
 670 Quando si chiama \func{connect} su di un socket UDP tutto quello che succede è
 671 che l'indirizzo passato alla funzione viene registrato come indirizzo di
 672 destinazione del socket. A differenza di quanto avviene con TCP non viene
 673 scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
 674 qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
 675 più necessario usare l'argomento \param{to} di \func{sendto} per specificare
 676 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
 677 le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
 678   anche continuare ad usare la funzione \func{sendto}, ma in tal caso
 679   l'argomento \param{to} deve essere inizializzato a \val{NULL}, e
 680   \param{tolen} deve essere inizializzato a zero, pena un errore.}
 681
 682 Una volta che il socket è connesso cambia però anche il comportamento in
 683 ricezione; prima infatti il kernel avrebbe restituito al socket qualunque
 684 pacchetto ricevuto con un indirizzo di destinazione corrispondente a quello
 685 del socket, senza nessun controllo sulla sorgente; una volta che il socket
 686 viene connesso saranno riportati su di esso solo i pacchetti con un indirizzo
 687 sorgente corrispondente a quello a cui ci si è connessi.
 688
 689 Infine quando si usa un socket connesso, venendo meno l'ambiguità segnalata
 690 alla fine di sez.~\ref{sec:UDP_problems}, tutti gli eventuali errori asincroni
 691 vengono riportati alle funzioni che operano su di esso; pertanto potremo
 692 riscrivere il nostro client per il servizio \textit{echo} con le modifiche
 693 illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
 694
 695 \begin{figure}[!htbp]
 696   \footnotesize \centering
 697   \begin{minipage}[c]{\codesamplewidth}
 698     \includecodesample{listati/UDP_echo.c}
 699   \end{minipage}
 700   \normalsize
 701   \caption{Seconda versione del client del servizio \textit{echo} che utilizza
 702     socket UDP connessi.}
 703   \label{fig:UDP_echo_conn_cli}
 704 \end{figure}
 705
 706 Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
 707 l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
 708 chiamata alla funzione di gestione del protocollo, che a sua volta è stata
 709 modificata eliminando l'indirizzo passato come argomento e sostituendo le
 710 chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
 711 \func{write} come illustrato dal nuovo codice riportato in
 712 fig.~\ref{fig:UDP_echo_conn_echo_client}.
 713
 714 \begin{figure}[!htbp]
 715   \footnotesize \centering
 716   \begin{minipage}[c]{\codesamplewidth}
 717     \includecodesample{listati/UDP_ClientEcho.c}
 718   \end{minipage}
 719   \normalsize
 720   \caption{Seconda versione della funzione \func{ClientEcho}.}
 721   \label{fig:UDP_echo_conn_echo_client}
 722 \end{figure}
 723
 724 Utilizzando questa nuova versione del client si può verificare che quando ci
 725 si rivolge verso un indirizzo inesistente o su cui non è in ascolto un server
 726 si è in grado rilevare l'errore, se infatti eseguiamo il nuovo programma
 727 otterremo un qualcosa del tipo:
 728 \begin{verbatim}
 729 [piccardi@gont sources]$ ./echo 192.168.1.1
 730 prova
 731 Errore in lettura: Connection refused
 732 \end{verbatim}%$
 733
 734 Ma si noti che a differenza di quanto avveniva con il client TCP qui l'errore
 735 viene rilevato soltanto dopo che si è tentato di inviare qualcosa, ed in
 736 corrispondenza al tentativo di lettura della risposta. Questo avviene perché
 737 con UDP non esiste una connessione, e fintanto che non si invia un pacchetto
 738 non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
 739 ricezione del pacchetto ICMP \textit{destination unreachable} emesso dalla
 740 macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
 741 il kernel potrà riportare detto errore in user space in maniera non ambigua,
 742 ed esso apparirà alla successiva lettura sul socket.
 743
 744 Si tenga presente infine che l'uso dei socket connessi non risolve l'altro
 745 problema del client, e cioè il fatto che in caso di perdita di un pacchetto
 746 questo resterà bloccato permanentemente in attesa di una risposta. Per
 747 risolvere questo problema l'unico modo sarebbe quello di impostare un
 748 \textit{timeout} o riscrivere il client in modo da usare l'I/O non bloccante.
 749
 750
 751
 752 \index{socket!locali|(}
 753
 754
 755 \section{I socket \textit{Unix domain}}
 756 \label{sec:unix_socket}
 757
 758 Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
 759 girano sulla stessa macchina, non siano strettamente attinenti alla rete, li
 760 tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
 761 l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella
 762 dei socket.
 763
 764
 765
 766 \subsection{Il passaggio di file descriptor}
 767 \label{sec:sock_fd_passing}
 768
 769
 770
 771 \index{socket!locali|)}
 772
 773
 774 \section{Altri socket}
 775 \label{sec:socket_other}
 776
 777 Tratteremo in questa sezione gli altri tipi particolari di socket supportati
 778 da Linux, come quelli relativi a particolare protocolli di trasmissione, i
 779 socket \textit{netlink} che definiscono una interfaccia di comunicazione con
 780 il kernel, ed i \textit{packet socket} che consentono di inviare pacchetti
 781 direttamente a livello delle interfacce di rete.
 782
 783 \subsection{I socket \textit{raw}}
 784 \label{sec:socket_raw}
 785
 786 Tratteremo in questa sezione i cosiddetti \textit{raw socket}, con i quali si
 787 possono \textsl{forgiare} direttamente i pacchetti a tutti i livelli dello
 788 stack dei protocolli.
 789
 790 \subsection{I socket \textit{netlink}}
 791 \label{sec:socket_netlink}
 792
 793
 794 \subsection{I \textit{packet socket}}
 795 \label{sec:packet_socket}
 796
 797
 798 % articoli interessanti:
 799 % http://www.linuxjournal.com/article/5617
 800 % http://www.linuxjournal.com/article/4659
 801 %
 802
 803
 804 % LocalWords:  socket cap TCP UDP domain sez NFS DNS stream datagram PF INET to
 805 % LocalWords:  IPv tab SOCK DGRAM three way handshake client fig bind listen AF
 806 % LocalWords:  accept recvfrom sendto connect netstat named DHCP kernel ICMP CR
 807 % LocalWords:  port unreachable read write glibc Specification flags int BSD LF
 808 % LocalWords:  libc unsigned len size tolen sys ssize sockfd const void buf MSG
 809 % LocalWords:  struct sockaddr socklen errno EAGAIN ECONNRESET EDESTADDRREQ RFC
 810 % LocalWords:  EISCONN EMSGSIZE ENOBUFS ENOTCONN EOPNOTSUPP EPIPE SIGPIPE EBADF
 811 % LocalWords:  NOSIGNAL EFAULT EINVAL EINTR ENOMEM ENOTSOCK NULL fromlen from
 812 % LocalWords:  ECONNREFUSED value result argument close shutdown daytime nell'
 813 % LocalWords:  memset inet pton nread NUL superdemone inetd sniffer daytimed
 814 % LocalWords:  INADDR ANY addr echo ClientEcho sendbuff serv VPN tcpdump l'I
 815 % LocalWords:  Stevens destination descriptor raw stack netlink packet
 816
 817
 818
 819 %%% Local Variables:
 820 %%% mode: latex
 821 %%% TeX-master: "gapil"
 822 %%% End: