Aggiornamento alla versione reale
[gapil.git] / socket.tex
1 %% socket.tex
2 %%
3 %% Copyright (C) 2000-2002 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 "Prefazione",
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 \chapter{Introduzione ai socket}
12 \label{cha:socket_intro}
13
14 In questo capitolo inizieremo a spiegare le caratteristiche salienti della
15 principale interfaccia per la programmazione di rete, quella dei
16 \textit{socket}, che, pur essendo nata in ambiente Unix è usata ormai da tutti
17 i sistemi operativi.
18
19 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
20 come creare un socket e come collegarlo allo specifico protocollo di rete che
21 si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
22 teorica concluderemo il capitolo con un primo esempio di applicazione.
23
24 \section{Una panoramica}
25 \label{sec:sock_overview}
26
27 Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di
28 quali sono i concetti fondamentali da tenere presente quando si ha a che fare
29 con essi.
30 \index{socket|(}
31
32
33 \subsection{I \textit{socket}}
34 \label{sec:sock_socket_def}
35
36 I \textit{socket}\footnote{una traduzione letterale potrebbe essere
37   \textsl{presa}, ma essendo universalmente noti come \textit{socket}
38   utilizzeremo sempre la parola inglese.} sono uno dei principali meccanismi
39 di comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati
40 in \secref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione fra
41 processi. Un socket costituisce in sostanza un canale di comunicazione fra due
42 processi su cui si possono leggere e scrivere dati analogo a quello di una
43 pipe (vedi \secref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
44 meccanismi esaminati nel capitolo \capref{cha:IPC}, i socket non sono limitati
45 alla comunicazione fra processi che girano sulla stessa macchina, ma possono
46 realizzare la comunicazione anche attraverso la rete.
47
48 Quella dei socket costituisce infatti la principale interfaccia usata nella
49 programmazione di rete.  La loro origine risale al 1983, quando furono
50 introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
51 piccole modifiche, negli anni successivi. Benché siano state sviluppate
52 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
53   Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
54 di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
55
56 La flessibilità e la genericità dell'interfaccia inoltre consente di
57 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
58 solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
59 di cui tratteremo in maniera più estesa.
60
61
62 \subsection{Concetti base}
63 \label{sec:sock_gen}
64
65 Per capire il funzionamento dei socket occorre avere presente il funzionamento
66 dei protocolli di rete (vedi \capref{cha:network}), ma l'interfaccia è del
67 tutto generale e benché le problematiche (e quindi le modalità di risolvere i
68 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
69 usato, le funzioni da usare restano le stesse.
70
71 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
72 inutile, in quanto il comportamento di quest'ultima e le problematiche da
73 affrontare cambiano radicalmente a seconda dello \textsl{stile} di
74 comunicazione usato.  La scelta di questo stile va infatti ad incidere sulla
75 semantica che verrà utilizzata a livello utente per gestire la comunicazione
76 (su come inviare e ricevere i dati) e sul comportamento effettivo delle
77 funzioni utilizzate.
78
79 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
80 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
81 comunicazione considerano i dati come una sequenza continua di byte, in quello
82 che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
83 altri invece li raggruppano in \textsl{pacchetti} (in inglese
84 \textit{datagram}) che vengono inviati in blocchi separati.
85
86 Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
87 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
88 inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
89
90 Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
91 avviene, in certi casi essa può essere condotta con una connessione diretta
92 con un solo corrispondente, come per una telefonata; altri casi possono
93 prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
94 ogni pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
95 radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove
96 chiunque si collega possa riceverli.
97
98 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
99 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
100 gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
101 dovranno essere opportunamente trattati, ecc.
102
103
104 \section{La creazione di un \textit{socket}}
105 \label{sec:sock_creation}
106
107 Come accennato l'interfaccia dei socket è estremamente flessibile e permette
108 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
109 in questa sezione vedremo come è possibile creare un socket e come specificare
110 il tipo di comunicazione che esso deve utilizzare.
111
112 \subsection{La funzione \func{socket}}
113 \label{sec:sock_socket}
114
115 La creazione di un socket avviene attraverso l'uso della funzione
116 \funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
117   tutto analogo a quelli che si ottengono per i file di dati e le pipe,
118   descritti in \secref{sec:file_fd}.} che serve come riferimento al socket; il
119 suo prototipo è:
120 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
121
122   Apre un socket.
123   
124   \bodydesc{La funzione restituisce un intero positivo in caso di successo, e
125     -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
126   i valori:
127   \begin{errlist}
128   \item[\errcode{EPROTONOSUPPORT}] Il tipo di socket o il protocollo scelto non
129     sono supportati nel dominio.
130   \item[\errcode{ENFILE}] Il kernel non ha memoria sufficiente a creare una
131     nuova struttura per il socket.
132   \item[\errcode{EMFILE}] Si è ecceduta la tabella dei file.
133   \item[\errcode{EACCES}] Non si hanno privilegi per creare un socket nel
134     dominio o con il protocollo specificato.
135   \item[\errcode{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
136   \item[\errcode{ENOBUFS}] Non c'è sufficiente memoria per creare il socket
137     (può essere anche \errval{ENOMEM}).
138   \end{errlist}
139   inoltre, a seconda del protocollo usato, potranno essere generati altri
140   errori, che sono riportati nelle relative pagine di manuale.}
141 \end{prototype}
142
143 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
144 (definisce cioè, come vedremo in \secref{sec:sock_domain}, la famiglia di
145 protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
146 come vedremo in \secref{sec:sock_type}, lo stile di comunicazione) e
147 \param{protocol} il protocollo; in genere quest'ultimo è indicato
148 implicitamente dal tipo di socket, per cui di norma questo valore viene messo
149 a zero (con l'eccezione dei \textit{raw socket}).
150
151 Si noti che la creazione del socket si limita ad allocare le opportune
152 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
153 non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
154 attraverso i quali si vuole effettuare la comunicazione.
155
156 \subsection{Il dominio, o \textit{protocol family}}
157 \label{sec:sock_domain}
158
159 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
160 tipi di socket, che vengono classificati raggruppandoli in quelli che si
161 chiamano \textsl{domini}.  La scelta di un dominio equivale in sostanza alla
162 scelta di una famiglia di protocolli, e viene effettuata attraverso
163 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
164 suo nome simbolico che convenzionalmente inizia con una costante che inizia
165 per \texttt{PF\_}, iniziali di \textit{protocol family}, un altro nome con cui
166 si indicano i domini.
167
168 A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
169 associato ad una costante, che inizia invece per \texttt{AF\_} (da
170 \textit{address family}) che identifica il formato degli indirizzi usati in
171 quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
172 anche come \textit{name space},\footnote{nome che invece il manuale delle
173   \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
174 identificano il formato degli indirizzi usati in quel dominio per identificare
175 i capi della comunicazione.
176
177 \begin{table}[htb]
178   \footnotesize
179   \centering
180   \begin{tabular}[c]{|l|l|l|l|}
181        \hline
182        \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
183        \hline
184        \hline
185        \const{PF\_UNSPEC}   & 0& Non specificato               &            \\
186        \const{PF\_LOCAL}    & 1& Local communication           & unix(7)    \\
187        \const{PF\_UNIX}, \const{PF\_FILE}&1&                   &            \\
188        \const{PF\_INET}     & 2& IPv4 Internet protocols       & ip(7)      \\
189        \const{PF\_AX25}     & 3& Amateur radio AX.25 protocol  &            \\
190        \const{PF\_IPX}      & 4& IPX - Novell protocols        &            \\
191        \const{PF\_APPLETALK}& 5& Appletalk                     & ddp(7)     \\
192        \const{PF\_NETROM}   & 6& Amateur radio NetROM          &            \\
193        \const{PF\_BRIDGE}   & 7& Multiprotocol bridge          &            \\
194        \const{PF\_ATMPVC}   & 8& Access to raw ATM PVCs        &            \\
195        \const{PF\_X25}      & 9& ITU-T X.25 / ISO-8208 protocol& x25(7)     \\
196        \const{PF\_INET6}    &10& IPv6 Internet protocols       & ipv6(7)    \\
197        \const{PF\_ROSE}     &11& Amateur Radio X.25 PLP        &            \\
198        \const{PF\_DECnet}   &12& Reserved for DECnet project   &            \\
199        \const{PF\_NETBEUI}  &13& Reserved for 802.2LLC project &            \\
200        \const{PF\_SECURITY} &14& Security callback pseudo AF   &            \\
201        \const{PF\_KEY}      &15& PF\_KEY key management API    &            \\
202        \const{PF\_NETLINK}  &16& Kernel user interface device  & netlink(7) \\
203        \const{PF\_PACKET}   &17& Low level packet interface    & packet(7)  \\
204        \const{PF\_ASH}      &18& Ash                           &    \\
205        \const{PF\_ECONET}   &19& Acorn Econet                  &    \\
206        \const{PF\_ATMSVC}   &20& ATM SVCs                      &    \\
207        \const{PF\_SNA}      &22& Linux SNA Project             &    \\
208        \const{PF\_IRDA}     &23& IRDA sockets                  &    \\
209        \const{PF\_PPPOX}    &24& PPPoX sockets                 &    \\
210        \const{PF\_WANPIPE}  &25& Wanpipe API sockets           &    \\
211        \const{PF\_BLUETOOTH}&31& Bluetooth sockets             &    \\
212        \hline
213   \end{tabular}
214   \caption{Famiglie di protocolli definiti in Linux.}
215   \label{tab:net_pf_names}
216 \end{table}
217
218 L'idea alla base della distinzione fra questi due insiemi di costanti era che
219 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
220 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
221 il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
222 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
223 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
224 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
225 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
226   il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
227   e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
228   lo stesso nome.}
229
230 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
231 indirizzi, sono definiti dall'header \textit{socket.h}. Un elenco delle
232 famiglie di protocolli disponibili in Linux è riportato in
233 \tabref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
234   definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
235   compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
236   viene definita anche una costante \const{PF\_MAX} che indica il valore
237   massimo associabile ad un dominio (nel caso il suo valore 32).}
238
239 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
240 dall'utente generico, ad esempio in generale tutti i socket di tipo
241 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
242 di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
243 capability \texttt{CAP\_NET\_RAW}.
244
245
246 \subsection{Il tipo, o stile}
247 \label{sec:sock_type}
248
249 La scelta di un dominio non comporta però la scelta dello stile di
250 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
251 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
252 socket permette di scegliere lo stile di comunicazione indicando il tipo di
253 socket con l'argomento \param{type} di \func{socket}. Linux mette a
254 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
255 della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
256 seguenti costanti:
257
258 \begin{basedescript}{\desclabelwidth{2.8cm}\desclabelstyle{\nextlinelabel}}
259 \item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati
260   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
261   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
262   byte (da cui il nome \textit{stream}).
263 \item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
264   (\textit{datagram}) di lunghezza massima fissata indirizzati singolarmente,
265   Non esiste una connessione e la trasmissione è effettuata in maniera non
266   affidabile.
267 \item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
268   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
269   altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
270   massima fissata, ed devono essere letti integralmente da ciascuna
271   chiamata a \func{read}.
272 \item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
273   rete e alle varie interfacce. I normali programmi di comunicazione non
274   devono usarlo, è riservato all'uso di sistema.
275 \item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
276   affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
277 \item[\const{SOCK\_PACKET}] Obsoleto, non deve essere usato.
278 \end{basedescript}
279
280 Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
281 e un tipo di socket sono valide, in quanto non è detto che in una famiglia
282 esista un protocollo per ciascuno dei diversi stili di comunicazione appena
283 elencati.
284
285 \begin{table}[htb]
286   \footnotesize
287   \centering
288   \begin{tabular}{|l|c|c|c|c|c|}
289     \hline
290     \multicolumn{1}{|c|}{\textbf{Famiglia}}&
291     \multicolumn{5}{|c|}{\textbf{Tipo}}\\
292     \hline
293     \hline
294     &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM}     &\const{SOCK\_RAW}& 
295       \const{SOCK\_PACKET}&\const{SOCK\_SEQPACKET} \\
296      \hline
297     \const{PF\_UNIX}      &  si & si  &      &     &     \\
298      \hline
299     \const{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
300      \hline
301     \const{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
302      \hline
303     \const{PF\_IPX}       &     &     &      &     &     \\
304      \hline
305     \const{PF\_NETLINK}   &     &  si &  si  &     &     \\
306      \hline
307     \const{PF\_X25}       &     &     &      &     &  si \\
308      \hline
309     \const{PF\_AX25}      &     &     &      &     &     \\
310      \hline
311     \const{PF\_ATMPVC}    &     &     &      &     &     \\
312      \hline
313     \const{PF\_APPLETALK} &     & si  &  si  &     &     \\
314      \hline
315     \const{PF\_PACKET}    &     & si  & si   &     &     \\    
316      \hline
317   \end{tabular}
318   \caption{Combinazioni valide di dominio e tipo di protocollo per la 
319     funzione \func{socket}.}
320   \label{tab:sock_sock_valid_combinations}
321 \end{table}
322
323 In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
324 valide possibili per le principali famiglie di protocolli. Per ogni
325 combinazione valida si è indicato il tipo di protocollo, o la parola
326 \textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
327 sono lasciate vuote le caselle per le combinazioni non supportate.
328
329
330 \section{Le strutture degli indirizzi dei socket}
331 \label{sec:sock_sockaddr}
332
333 Come si è visto nella creazione di un socket non si specifica nulla oltre al
334 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
335 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
336 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
337 comunicazione.
338
339 Gli indirizzi infatti vengono specificati attraverso apposite strutture che
340 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
341 la comunicazione viene effettivamente realizzata.  Ogni famiglia di protocolli
342 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
343 sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
344 iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
345 identificati dal suffisso finale, aggiunto al nome precedente.
346
347
348 \subsection{La struttura generica}
349 \label{sec:sock_sa_gen}
350
351 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
352 attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
353 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
354 nelle varie famiglie di protocolli; questo pone il problema di come passare
355 questi puntatori, il C moderno risolve questo problema coi i puntatori
356 generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
357 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
358 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
359 è riportata in \figref{fig:sock_sa_gen_struct}.
360
361 \begin{figure}[!htb]
362   \footnotesize \centering
363   \begin{minipage}[c]{15cm}
364     \includestruct{listati/sockaddr.h}
365   \end{minipage} 
366   \caption{La struttura generica degli indirizzi dei socket
367     \structd{sockaddr}.} 
368   \label{fig:sock_sa_gen_struct}
369 \end{figure}
370
371 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
372 prototipo un puntatore a questa struttura; per questo motivo quando si
373 invocano dette funzioni passando l'indirizzo di un protocollo specifico
374 occorrerà eseguire una conversione del relativo puntatore.
375
376 I tipi di dati che compongono la struttura sono stabiliti dallo standard
377 POSIX.1g e li abbiamo riassunti in \tabref{tab:sock_data_types} con i
378 rispettivi file di include in cui sono definiti; la struttura è invece
379 definita nell'include file \file{sys/socket.h}.
380
381 \begin{table}[!htb]
382   \centering
383   \footnotesize
384   \begin{tabular}{|l|l|l|}
385     \hline
386     \multicolumn{1}{|c|}{\textbf{Tipo}}& 
387     \multicolumn{1}{|c|}{\textbf{Descrizione}}& 
388     \multicolumn{1}{|c|}{\textbf{Header}} \\
389     \hline
390     \hline
391     \type{int8\_t}   & intero a 8 bit con segno   & \file{sys/types.h}\\
392     \type{uint8\_t}  & intero a 8 bit senza segno & \file{sys/types.h}\\
393     \type{int16\_t}  & intero a 16 bit con segno  & \file{sys/types.h}\\
394     \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
395     \type{int32\_t}  & intero a 32 bit con segno  & \file{sys/types.h}\\
396     \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
397     \hline
398     \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
399     \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
400     un socket& \file{sys/socket.h}\\
401     \hline
402     \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & 
403     \file{netinet/in.h}\\
404     \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& 
405     \file{netinet/in.h}\\
406     \hline
407   \end{tabular}
408   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 
409     stabilito dallo standard POSIX.1g.}
410   \label{tab:sock_data_types}
411 \end{table}
412
413 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
414 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
415 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
416 non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
417 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
418
419 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
420 di fare da riferimento per il casting, per il kernel le cose sono un po'
421 diverse, in quanto esso usa il puntatore per recuperare il campo
422 \var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
423 indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
424 sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
425 è stato mantenuto l'uso di questa struttura.
426
427
428 \subsection{La struttura degli indirizzi IPv4}
429 \label{sec:sock_sa_ipv4}
430
431 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
432 attraverso internet; la struttura per gli indirizzi per un socket internet (se
433 si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
434 \file{netinet/in.h} ed ha la forma mostrata in
435 \figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
436
437 \begin{figure}[!htb]
438   \footnotesize\centering
439   \begin{minipage}[c]{15cm}
440     \includestruct{listati/sockaddr_in.h}
441   \end{minipage} 
442   \caption{La struttura degli indirizzi dei socket internet (IPv4)
443     \structd{sockaddr\_in}.}
444   \label{fig:sock_sa_ipv4_struct}
445 \end{figure}
446
447 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
448 internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
449 dettaglio il significato di questi numeri in \secref{sec:TCP_port_num}).  Il
450 protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
451 protocolli di livello superiore come TCP e UDP. Questa struttura però viene
452 usata anche per i socket RAW che accedono direttamente al livello di IP, nel
453 qual caso il numero della porta viene impostato al numero di protocollo.
454
455 Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
456 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
457 specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
458 chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
459 soltanto processi con i privilegi di amministratore (con user-ID effettivo
460 uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
461 usare la funzione \func{bind} (che vedremo in \secref{sec:TCP_func_bind}) su
462 queste porte.
463
464 Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
465 come struttura (un resto di una implementazione precedente in cui questa era
466 una \direct{union} usata per accedere alle diverse classi di indirizzi) che
467 direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
468 costanti che identificano alcuni indirizzi speciali, riportati in
469 \tabref{tab:TCP_ipv4_addr}.
470
471 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
472 essere specificati in quello che viene chiamato \textit{network order}, cioè
473 con i bit ordinati in formato \textit{big endian}, questo comporta la
474 necessità di usare apposite funzioni di conversione per mantenere la
475 portabilità del codice (vedi \secref{sec:sock_addr_func} per i dettagli del
476 problema e le relative soluzioni).
477
478
479 \subsection{La struttura degli indirizzi IPv6}
480 \label{sec:sock_sa_ipv6}
481
482 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
483 sostanzialmente identici ai precedenti; la parte in cui si trovano
484 praticamente tutte le differenze fra i due socket è quella della struttura
485 degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
486 in \figref{fig:sock_sa_ipv6_struct}.
487
488 \begin{figure}[!htb]
489   \footnotesize \centering
490   \begin{minipage}[c]{15cm}
491     \includestruct{listati/sockaddr_in6.h}
492   \end{minipage} 
493   \caption{La struttura degli indirizzi dei socket IPv6 
494     \structd{sockaddr\_in6}.}
495   \label{fig:sock_sa_ipv6_struct}
496 \end{figure}
497
498 Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
499 il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
500 il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
501 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
502 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
503 specifici dell'header dei pacchetti IPv6 (vedi \secref{sec:IP_ipv6head}) ed il
504 loro uso è sperimentale.
505
506 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, infine
507 il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il kernel
508 2.4, per gestire alcune operazioni riguardanti il multicasting.
509  
510 Si noti che questa struttura ha una dimensione maggiore della struttura
511 \struct{sockaddr} generica vista in \figref{fig:sock_sa_gen_struct}, quindi
512 occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
513 di contenere i dati nelle dimensioni di quest'ultima.
514
515
516 \subsection{La struttura degli indirizzi locali}
517 \label{sec:sock_sa_local}
518
519 I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
520 comunicazione fra processi che stanno sulla stessa macchina (per questo
521 vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
522 hanno la caratteristica ulteriore di poter essere creati anche in maniera
523 anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
524 \secref{sec:ipc_socketpair}).  Quando però si vuole fare riferimento esplicito
525 ad uno di questi socket si deve usare una struttura degli indirizzi di tipo
526 \struct{sockaddr\_un}, la cui definizione si è riportata in
527 \secref{fig:sock_sa_local_struct}.
528
529 \begin{figure}[!htb]
530   \footnotesize \centering
531   \begin{minipage}[c]{15cm}
532     \includestruct{listati/sockaddr_un.h}
533   \end{minipage} 
534   \caption{La struttura degli indirizzi dei socket locali (detti anche
535     \textit{unix domain}) \structd{sockaddr\_un} definita in \file{sys/un.h}.}
536   \label{fig:sock_sa_local_struct}
537 \end{figure}
538
539 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
540 il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
541 può essere un file (di tipo socket) nel filesystem o una stringa univoca
542 (mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
543 specificato come una stringa (terminata da uno zero) corrispondente al
544 pathname del file; nel secondo invece \var{sun\_path} inizia con uno zero e
545 vengono usati come nome i restanti byte come stringa, senza terminazione.
546
547
548 \subsection{La struttura degli indirizzi AppleTalk}
549 \label{sec:sock_sa_appletalk}
550
551 I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
552 \file{netatalk} per implementare la comunicazione secondo il protocollo
553 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
554 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
555 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
556 opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
557 questo argomento principalmente per mostrare l'uso di un protocollo
558 alternativo.
559
560 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
561 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
562 \func{socket} deve essere nullo. È altresì possibile usare i socket raw
563 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
564 per \param{protocol} è \func{ATPROTO\_DDP}.
565
566 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
567 \struct{sockaddr\_atalk}, la cui definizione è riportata in
568 \figref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo il
569 file \file{netatalk/at.h}.
570
571 \begin{figure}[!htb]
572   \footnotesize \centering
573   \begin{minipage}[c]{15cm}
574     \includestruct{listati/sockaddr_atalk.h}
575   \end{minipage} 
576   \caption{La struttura degli indirizzi dei socket AppleTalk 
577     \structd{sockaddr\_atalk}.}
578   \label{fig:sock_sa_atalk_struct}
579 \end{figure}
580
581 Il campo \var{sat\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
582 campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
583 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
584 usati solo da processi con i privilegi di amministratore o con la capability
585 \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
586 struttura \var{sat\_addr}, e deve essere in \textit{network order} (vedi
587 \secref{sec:sock_endianess}); esso è composto da un parte di rete data dal
588 campo \var{s\_net}, che può assumere il valore \const{AT\_ANYNET}, che indica
589 una rete generica e vale anche per indicare la rete su cui si è, il singolo
590 nodo è indicato da \var{s\_node}, e può prendere il valore generico
591 \const{AT\_ANYNODE} che indica anche il nodo corrente, ed il valore
592 \const{ATADDR\_BCAST} che indica tutti i nodi della rete.
593
594
595 \subsection{La struttura degli indirizzi dei \textit{packet socket}}
596 \label{sec:sock_sa_packet}
597
598 I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
599 un'interfaccia specifica di Linux per inviare e ricevere pacchetti
600 direttamente su un'interfaccia di rete, senza passare per le routine di
601 gestione dei protocolli di livello superiore. In questo modo è possibile
602 implementare dei protocolli in user space, agendo direttamente sul livello
603 fisico. In genere comunque si preferisce usare la libreria \file{pcap}, che
604 assicura la portabilità su altre piattaforme, anche se con funzionalità
605 ridotte.
606
607 Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
608 Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
609 collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
610 del dispositivo e viceversa.  In questo modo, in fase di trasmissione, il
611 contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
612 fornito dall'utente. In fase di ricezione invece tutto il contenuto del
613 pacchetto viene passato inalterato sul socket, anche se il kernel analizza
614 comunque il pacchetto, riempiendo gli opportuni campi della struttura
615 \struct{sockaddr\_ll} ad esso associata.
616
617 Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
618 livello di rete. In questo caso in fase di ricezione l'intestazione del
619 protocollo di collegamento viene rimossa prima di passare il resto del
620 pacchetto all'utente, mentre in fase di trasmissione viene creata una
621 opportuna intestazione per il protocollo a livello di collegamento
622 utilizzato, usando le informazioni necessarie che devono essere specificate
623 sempre con una struttura \struct{sockaddr\_ll}.
624
625 Nella creazione di un \textit{packet socket} il valore dell'argomento
626 \param{protocol} di \func{socket} serve a specificare, in \textit{network
627   order}, il numero identificativo del protocollo di collegamento si vuole
628 utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
629 quelli disponibili in Linux sono accessibili attraverso opportune costanti
630 simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
631 speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
632 pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
633 di questi socket è una operazione privilegiata e può essere effettuati solo da
634 un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
635 la capability \const{CAP\_NET\_RAW}.
636
637 Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
638 specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
639 provengono; se si vuole limitare il passaggio ad una interfaccia specifica
640 occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
641
642 \begin{figure}[!htb]
643   \footnotesize \centering
644   \begin{minipage}[c]{15cm}
645     \includestruct{listati/sockaddr_ll.h}
646   \end{minipage} 
647   \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
648     \textit{packet socket}.}
649   \label{fig:sock_sa_packet_struct}
650 \end{figure}
651
652 Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
653 \struct{sockaddr\_ll}, e la sua definizione è riportata in
654 \figref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
655 leggermente diverso rispetto a quanto visto finora per gli altri tipi di
656 socket.  Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
657 scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
658 specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
659 tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
660 al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
661 entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
662 pacchetto.
663
664 Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
665 \const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
666 e deve essere indicato in \textit{network order}, facendo uso delle costanti
667 simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
668 l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
669 stesso tipo (se ad esempio si hanno più schede ethernet), permette di
670 selezionare quella con cui si vuole operare (un valore nullo indica qualunque
671 interfaccia).  Questi sono i due soli campi che devono essere specificati
672 quando si vuole selezionare una interfaccia specifica, usando questa struttura
673 con la funzione \func{bind}.
674
675 I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
676 l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
677 relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
678 collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il
679 MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
680 ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
681 pacchetti, in questo caso tutti gli altri campi devono essere nulli.
682
683 Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
684 \file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
685 pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
686 senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
687 seguenti valori: \var{PACKET\_HOST} per un pacchetto indirizzato alla macchina
688 ricevente, \var{PACKET\_BROADCAST} per un pacchetto di broadcast,
689 \var{PACKET\_MULTICAST} per un pacchetto inviato ad un indirizzo fisico di
690 multicast, \var{PACKET\_OTHERHOST} per un pacchetto inviato ad un'altra
691 stazione (e ricevuto su un'interfaccia in modo promiscuo),
692 \var{PACKET\_OUTGOING} per un pacchetto originato dalla propria macchina che
693 torna indietro sul socket.
694
695 Si tenga presente infine che in fase di ricezione, anche se si richiede il
696 troncamento del pacchetto, le funzioni \func{recvmsg}, \func{recv} e
697 \func{recvfrom} restituiranno comunque la lunghezza effettiva del pacchetto
698 così come arrivato sulla linea.
699
700
701 %% \subsection{La struttura degli indirizzi DECnet}
702 %% \label{sec:sock_sa_decnet}
703  
704 %% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
705 %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
706 %% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
707 %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
708 %% solo come esempio 
709
710
711
712 % \subsection{Il passaggio delle strutture}
713 % \label{sec:sock_addr_pass}
714
715 % Come detto nelle funzioni della API dei socket le strutture degli indirizzi
716 % vengono sempre passate per riferimento usando un puntatore; anche la lunghezza
717 % della struttura è passata come argomento, ma in questo caso la modalità del
718 % passaggio dipende dalla direzione del medesimo, dal processo al kernel o
719 % viceversa.
720
721 % In particolare le tre funzioni \texttt{bind}, \texttt{connect} e
722 % \texttt{sendto} passano la struttura al kernel, in questo caso è passata
723 % \textsl{per valore} anche la dimensione della medesima
724
725
726 % Le funzioni \texttt{accept}, \texttt{recvfrom}, \texttt{getsockname} e
727 % \texttt{getpeername} invece ricevono i valori del kernel 
728
729
730
731 \section{Le funzioni di conversione degli indirizzi}
732 \label{sec:sock_addr_func}
733
734 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
735 indirizzi, limitandoci però agli indirizzi internet.
736
737 Come accennato gli indirizzi e i numeri di porta usati nella rete devono
738 essere forniti in formato opportuno (il \textit{network order}). Per capire
739 cosa significa tutto ciò occorre introdurre un concetto generale che tornerà
740 utile anche in seguito.
741
742
743 \subsection{La \textit{endianess}\index{endianess}}
744 \label{sec:sock_endianess}
745
746 La rappresentazione di un numero binario in un computer può essere fatta in
747 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
748   endian} a seconda di come i singoli bit vengono aggregati per formare le
749 variabili intere (ed in genere in diretta corrispondenza a come sono poi in
750 realtà cablati sui bus interni del computer).
751
752 Per capire meglio il problema si consideri un intero a 16 bit scritto in una
753 locazione di memoria posta ad un certo indirizzo. I singoli bit possono essere
754 disposti un memoria in due modi: a partire dal più significativo o a partire
755 dal meno significativo. Così nel primo caso si troverà il byte che contiene i
756 bit più significativi all'indirizzo menzionato e il byte con i bit meno
757 significativi nell'indirizzo successivo; questo ordinamento è detto
758 \textit{little endian} dato che il dato finale è la parte ``piccola'' del
759 numero. Il caso opposto, in cui si parte dal bit meno significativo è detto
760 per lo stesso motivo \textit{big endian}.
761
762 La \textit{endianess}\index{endianess} di un computer dipende essenzialmente
763 dalla architettura hardware usata; Intel e Digital usano il \textit{little
764   endian}, Motorola, IBM, Sun (sostanzialmente tutti gli altri) usano il
765 \textit{big endian}. Il formato della rete è anch'esso \textit{big endian},
766 altri esempi di uso di questi formati sono quello del bus PCI, che è
767 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
768
769 Esistono poi anche dei processori che possono scegliere il tipo di formato
770 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
771 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
772 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
773 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
774 questi cambiamenti.
775
776 \subsection{Le funzioni per il riordinamento}
777 \label{sec:sock_func_ord}
778
779 Il problema connesso all'endianess\index{endianess} è che quando si passano
780 dei dati da un tipo di architettura all'altra i dati vengono interpretati in
781 maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
782 con i due byte in cui è suddiviso scambiati di posto, e ne sarà quindi
783 invertito l'ordine di lettura per cui, per riavere il valore originale,
784 dovranno essere rovesciati.
785
786 Per questo motivo si usano delle funzioni di conversione che servono a tener
787 conto automaticamente della possibile differenza fra l'ordinamento usato sul
788 computer e quello che viene usato nelle trasmissione sulla rete; queste
789 funzioni sono \funcd{htonl}, \funcd{htons}, \funcd{ntonl} e \funcd{ntons} ed i
790 rispettivi prototipi sono:
791 \begin{functions}
792   \headdecl{netinet/in.h}
793   \funcdecl{unsigned long int htonl(unsigned long int hostlong)} 
794   Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
795   quello della rete.
796  
797   \funcdecl{unsigned short int htons(unsigned short int hostshort)}
798   Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
799   quello della rete.
800
801   \funcdecl{unsigned long int ntonl(unsigned long int netlong)}
802   Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
803   della macchina.
804
805   \funcdecl{unsigned sort int ntons(unsigned short int netshort)}
806   Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
807   della macchina.
808   
809   \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non
810     prevedono errori.}
811 \end{functions}
812
813 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
814 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
815 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
816 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
817 indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
818 prototipi).
819
820 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
821 macchina che si sta usando abbia una architettura \textit{big endian} queste
822 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
823 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
824 assicurare la portabilità del codice su tutte le architetture.
825
826
827 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e 
828   \func{inet\_ntoa}}
829 \label{sec:sock_func_ipv4}
830
831 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
832 binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
833 dei numeri IP che si usa normalmente.
834
835 Le prime tre funzioni di manipolazione riguardano la conversione degli
836 indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
837 cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
838 \texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
839   order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
840 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
841 \funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
842 \begin{functions}
843   \headdecl{arpa/inet.h}
844   
845   \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
846   dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
847
848   \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
849   la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
850
851   \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
852   Converte un indirizzo IP in una stringa \textit{dotted decimal}.
853
854   \bodydesc{Tutte queste le funzioni non generano codice di errore.}
855 \end{functions}
856
857 La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
858 network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
859 nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
860 un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
861 tipicamente sono trentadue bit a uno.  Questo però comporta che la stringa
862 \texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
863 con questa funzione; per questo motivo essa è generalmente deprecata in favore
864 di \func{inet\_aton}.
865
866 La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
867 nell'indirizzo binario che viene memorizzato nell'opportuna struttura
868 \struct{in\_addr} (si veda \secref{fig:sock_sa_ipv4_struct}) situata
869 all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
870 modo da poterla usare direttamente con il puntatore usato per passare la
871 struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
872 in caso di fallimento.  Se usata con \param{dest} inizializzato a \val{NULL}
873 effettua la validazione dell'indirizzo.
874
875 L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
876 dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
877 alla stringa che contiene l'espressione in formato dotted decimal. Si deve
878 tenere presente che la stringa risiede in memoria statica, per cui questa
879 funzione non è rientrante.
880
881
882 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
883 \label{sec:sock_conv_func_gen}
884
885 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
886 motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
887 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
888 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
889 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
890 e \textit{numeric}.
891
892 % \begin{figure}[htb]
893 %   \centering  
894
895 %   \caption{Schema della rappresentazioni utilizzate dalle funzioni di 
896 %     conversione \texttt{inet\_pton} e \texttt{inet\_ntop} }
897 %   \label{fig:sock_inet_conv_func}
898
899 % \end{figure}
900
901 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
902 indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
903 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
904 indirizzo; il suo prototipo è:
905 \begin{prototype}{sys/socket.h}
906 {int inet\_pton(int af, const char *src, void *addr\_ptr)} 
907
908   Converte l'indirizzo espresso tramite una stringa nel valore numerico.
909   
910   \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
911     una famiglia di indirizzi non valida, con \var{errno} che assume il valore
912     \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
913     indirizzo valido, ed un valore positivo in caso di successo.}
914 \end{prototype}
915
916 La funzione converte la stringa indicata tramite \param{src} nel valore
917 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
918 memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
919 restituisce un valore positivo in caso di successo, nullo se la stringa non
920 rappresenta un indirizzo valido, e negativo se \param{af} specifica una
921 famiglia di indirizzi non valida.
922
923 La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
924 indirizzo in una stringa; il suo prototipo è:
925 \begin{prototype}{sys/socket.h}
926   {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
927   Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
928  
929   \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
930     convertita in caso di successo e \val{NULL} in caso di fallimento, nel
931     qual caso \var{errno} assume i valori: 
932     \begin{errlist}
933     \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
934       dell'indirizzo eccedono la lunghezza specificata da \param{len}.
935     \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
936       una valida.
937   \end{errlist}}
938 \end{prototype}
939
940 La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
941 in una stringa che viene copiata nel buffer puntato dall'indirizzo
942 \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
943 essere almeno \const{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
944 \const{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
945 comunque venire specificata attraverso il parametro \param{len}.
946
947 Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
948 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
949 per IPv6), che devono essere precedentemente allocate e passate attraverso il
950 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
951 può essere nullo e deve essere allocato precedentemente.
952
953 Il formato usato per gli indirizzi in formato di presentazione è la notazione
954 \textit{dotted decimal} per IPv4 e quello descritto in
955 \secref{sec:IP_ipv6_notation} per IPv6.
956
957 \index{socket|)}
958
959
960
961 %%% Local Variables: 
962 %%% mode: latex
963 %%% TeX-master: "gapil"
964 %%% End: