3 %% Copyright (C) 2000-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
13 \label{cha:socket_intro}
15 In questo capitolo inizieremo a spiegare le caratteristiche salienti della
16 principale interfaccia per la programmazione di rete, quella dei
17 \textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
18 tutti i sistemi operativi.
20 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
21 come creare un socket e come collegarlo allo specifico protocollo di rete che
22 si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
23 teorica concluderemo il capitolo con un primo esempio di applicazione.
25 \section{Introduzione ai socket}
26 \label{sec:sock_overview}
28 In questa sezione daremo descrizione essenziale di cosa sono i \textit{socket}
29 e di quali sono i concetti fondamentali da tenere presente quando si ha a che
30 fare con essi; ne illustreremo poi le caratteristiche e le differenti
31 tipologie presenti ed infine tratteremo le modalità con cui possono essere
34 \index{socket!definizione|(}
36 \subsection{Cosa sono \textit{socket}}
37 \label{sec:sock_socket_def}
39 I \textit{socket} (una traduzione letterale potrebbe essere \textsl{presa}, ma
40 essendo universalmente noti come \textit{socket} utilizzeremo sempre la parola
41 inglese) sono uno dei principali meccanismi di comunicazione utilizzato in
42 ambito Unix, e li abbiamo brevemente incontrati in
43 sez.~\ref{sec:ipc_socketpair}, fra i vari meccanismi di intercomunicazione fra
46 Un socket costituisce in sostanza un canale di comunicazione fra due processi
47 su cui si possono leggere e scrivere dati analogo a quello di una
48 \textit{pipe} (vedi sez.~\ref{sec:ipc_pipes}) ma, a differenza di questa e
49 degli altri meccanismi esaminati nel capitolo cap.~\ref{cha:IPC}, i socket non
50 sono limitati alla comunicazione fra processi che girano sulla stessa
51 macchina, ma possono realizzare la comunicazione anche attraverso la rete.
53 Quella dei socket costituisce infatti la principale interfaccia usata nella
54 programmazione di rete. La loro origine risale al 1983, quando furono
55 introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
56 piccole modifiche, negli anni successivi. Benché siano state sviluppate
57 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
58 Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
59 di quella dei socket (né tantomeno la stessa usabilità e flessibilità) ed oggi
60 sono praticamente dimenticate.
62 La flessibilità e la genericità dell'interfaccia inoltre consente di
63 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
64 solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
65 di cui tratteremo in maniera più estesa.
67 Per capire il funzionamento dei socket occorre avere presente il funzionamento
68 dei protocolli di rete che su utilizzeranno (ed in particolare quelli del
69 TCP/IP già illustrati in sez.~\ref{sec:net_tpcip}), ma l'interfaccia è del
70 tutto generale e benché le problematiche, e quindi le modalità di risolvere i
71 problemi, siano diverse a seconda del tipo di protocollo di comunicazione
72 usato, le funzioni da usare nella gestione dei socket restano le stesse.
74 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
75 inutile, in quanto il comportamento di quest'ultima e le problematiche da
76 affrontare cambiano radicalmente a seconda del tipo di comunicazione usato.
77 La scelta di questo tipo di comunicazione (sovente anche detto \textsl{stile})
78 va infatti ad incidere sulla semantica che verrà utilizzata a livello utente
79 per gestire la comunicazione cioè su come inviare e ricevere i dati e sul
80 comportamento effettivo delle funzioni utilizzate.
82 La scelta di uno \textsl{stile} dipende sia dai meccanismi disponibili, sia
83 dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni tipi di
84 comunicazione considerano i dati come una sequenza continua di byte, in quello
85 che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
86 altri invece li raggruppano in \textsl{pacchetti} (in inglese
87 \textit{datagram}) che vengono sempre inviati in blocchi separati e non
90 Un altro esempio delle differenze fra i diversi tipi di comunicazione concerne
91 la possibilità che essa possa o meno perdere dati nella trasmissione, che
92 possa o meno rispettare l'ordine in cui i dati inviati e ricevuti, o che possa
93 accadere di inviare dei pacchetti di dati più volte (differenze che ad esempio
94 sono presenti nel caso di utilizzo dei protocolli TCP o UDP).
96 Un terzo esempio di differenza nel tipo di comunicazione concerne il modo in
97 cui essa avviene nei confronti dei corrispondenti, in certi casi essa può
98 essere condotta con una connessione diretta con un solo corrispondente, come
99 per una telefonata; altri casi possono prevedere una comunicazione come per
100 lettera, in cui si scrive l'indirizzo su ogni pacchetto, altri ancora una
101 comunicazione uno a molti come il \textit{broadcast} ed il \textit{multicast},
102 in cui i pacchetti possono venire emessi su appositi ``\textsl{canali}'' dove
103 chiunque si collega possa riceverli.
105 É chiaro che ciascuno di questi diversi aspetti è associato ad un tipo di
106 comunicazione che comporta una modalità diversa di gestire la stessa, ad
107 esempio se la comunicazione è inaffidabile occorrerà essere in grado di
108 gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
109 dovranno essere opportunamente trattati, se è uno a molti occorrerà tener
110 conto della eventuale unidirezionalità della stessa, ecc.
112 \index{socket!definizione|)}
115 \subsection{La creazione di un socket}
116 \label{sec:sock_creation}
118 Come accennato l'interfaccia dei socket è estremamente flessibile e permette
119 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
120 in questa sezione vedremo come è possibile creare un socket e come specificare
121 il tipo di comunicazione che esso deve utilizzare.
123 La creazione di un socket avviene attraverso l'uso della funzione di sistema
124 \funcd{socket}; essa restituisce un \textit{file descriptor} (del tutto
125 analogo a quelli che si ottengono per i file di dati e le \textit{pipe},
126 descritti in sez.~\ref{sec:file_fd}) che serve come riferimento al socket; il
131 \fdecl{int socket(int domain, int type, int protocol)}
132 \fdesc{Apre un socket.}
135 {La funzione ritorna un valore positivo in caso di successo e $-1$ per un
136 errore, nel qual caso \var{errno} assumerà uno dei valori:
138 \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
139 dominio o con il protocollo specificato.
140 \item[\errcode{EAFNOSUPPORT}] famiglia di indirizzi non supportata.
141 \item[\errcode{EINVAL}] argomento \param{type} invalido.
142 \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
143 \item[\errcode{ENFILE}] si è raggiunto il limite massimo di file aperti.
144 \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
145 (può essere anche \errval{ENOMEM}).
146 \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
147 non sono supportati nel dominio.
149 ed inoltre a seconda del protocollo usato, potranno essere generati altri
150 errori, che sono riportati nelle pagine di manuale relative al protocollo.}
154 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
155 (definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
156 protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
157 come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
158 \param{protocol} il protocollo; in genere quest'ultimo è indicato
159 implicitamente dal tipo di socket, per cui di norma questo valore viene messo
160 a zero (con l'eccezione dei \textit{raw socket}).
162 % TODO: l'ultimo argomento viene usato anche dai nuovi ping socket introdotti
163 % con il kernel 3.0, vedi anche http://lwn.net/Articles/420799/ e
164 % http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c319b4d76b9e583a5d88d6bf190e079c4e43213d
166 Si noti che la creazione del socket si limita ad allocare le opportune
167 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
168 non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
169 attraverso i quali si vuole effettuare la comunicazione. Questo significa che
170 la funzione da sola non è in grado di fornire alcun tipo di comunicazione.
173 \subsection{Il dominio dei socket}
174 \label{sec:sock_domain}
176 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
177 tipi di socket, che vengono classificati raggruppandoli in quelli che si
178 chiamano \textsl{domini}. La scelta di un dominio equivale in sostanza alla
179 scelta di una famiglia di protocolli, e viene effettuata attraverso
180 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
181 suo nome simbolico che convenzionalmente è indicato da una costante che inizia
182 per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
183 cui si indicano i domini.
185 A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
186 associato ad una costante, che inizia invece per \texttt{AF\_} (da
187 \textit{address family}) che identifica il formato degli indirizzi usati in
188 quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
189 anche come \textit{name space}, (nome che invece il manuale delle \acr{glibc}
190 riserva a quello che noi abbiamo chiamato domini) dato che identificano il
191 formato degli indirizzi usati in quel dominio per identificare i capi della
197 \begin{tabular}[c]{|l|l|l|l|}
199 \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
202 \constd{PF\_UNSPEC} & 0& Non specificato & \\
203 \constd{PF\_LOCAL} & 1& Local communication & unix(7) \\
204 \constd{PF\_UNIX}, \constd{PF\_FILE}&1&Sinonimi di \const{PF\_LOCAL}& \\
205 \constd{PF\_INET} & 2& IPv4 Internet protocols & ip(7) \\
206 \constd{PF\_AX25} & 3& Amateur radio AX.25 protocol & \\
207 \constd{PF\_IPX} & 4& IPX - Novell protocols & \\
208 \constd{PF\_APPLETALK}& 5& Appletalk & ddp(7) \\
209 \constd{PF\_NETROM} & 6& Amateur radio NetROM & \\
210 \constd{PF\_BRIDGE} & 7& Multiprotocol bridge & \\
211 \constd{PF\_ATMPVC} & 8& Access to raw ATM PVCs & \\
212 \constd{PF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\
213 \constd{PF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\
214 \constd{PF\_ROSE} &11& Amateur Radio X.25 PLP & \\
215 \constd{PF\_DECnet} &12& Reserved for DECnet project & \\
216 \constd{PF\_NETBEUI} &13& Reserved for 802.2LLC project & \\
217 \constd{PF\_SECURITY} &14& Security callback pseudo AF & \\
218 \constd{PF\_KEY} &15& PF\_KEY key management API & \\
219 \constd{PF\_NETLINK} &16& Kernel user interface device & netlink(7) \\
220 \constd{PF\_ROUTE} &16& Sinonimo di \const{PF\_NETLINK} emula BSD.&\\
221 \constd{PF\_PACKET} &17& Low level packet interface & packet(7) \\
222 \constd{PF\_ASH} &18& Ash & \\
223 \constd{PF\_ECONET} &19& Acorn Econet & \\
224 \constd{PF\_ATMSVC} &20& ATM SVCs & \\
225 \constd{PF\_SNA} &22& Linux SNA Project & \\
226 \constd{PF\_IRDA} &23& IRDA socket (infrarossi) & \\
227 \constd{PF\_PPPOX} &24& PPPoX socket & \\
228 \constd{PF\_WANPIPE} &25& Wanpipe API socket & \\
229 \constd{PF\_LLC} &26& Linux LLC & \\
230 \constd{PF\_CAN} &29& Controller Are network & \\
231 \constd{PF\_BLUETOOTH}&31& Bluetooth socket & \\
234 \caption{Famiglie di protocolli definiti in Linux.}
235 \label{tab:net_pf_names}
238 % TODO aggiungere PF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25
240 L'idea alla base della distinzione fra questi due insiemi di costanti era che
241 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
242 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
243 il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi. Questo è
244 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
245 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
246 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
247 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
248 il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
249 e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
250 lo stesso nome.} Qui si sono indicati i nomi con il prefisso \texttt{AF\_}
251 seguendo la convenzione usata nelle pagine di manuale.
253 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
254 indirizzi, sono definiti dall'\textit{header file} \headfiled{socket.h}. Un
255 elenco delle famiglie di protocolli disponibili in Linux è riportato in
256 tab.~\ref{tab:net_pf_names}. L'elenco indica tutti i protocolli definiti; fra
257 questi però saranno utilizzabili solo quelli per i quali si è compilato il
258 supporto nel kernel (o si sono caricati gli opportuni moduli), viene definita
259 anche una costante \constd{PF\_MAX} che indica il valore massimo associabile
262 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
263 dall'utente generico, ad esempio in generale tutti i socket di tipo
264 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
265 di amministratore (cioè con \ids{UID} effettivo uguale a zero) o dotati della
266 \textit{capability} \const{CAP\_NET\_RAW}.
269 \subsection{Il tipo di socket}
270 \label{sec:sock_type}
272 La scelta di un dominio non comporta però la scelta dello stile di
273 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
274 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
275 socket permette di scegliere lo stile di comunicazione indicando il tipo di
276 socket con l'argomento \param{type} di \func{socket}. Linux mette a
277 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
278 della \acr{glibc} \cite{GlibcMan} chiama \textit{styles}) identificati dalle
279 seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
280 tre tipi, Linux supporta anche gli altri, come si può verificare nel file
281 \texttt{include/linux/net.h} dei sorgenti del kernel.}
283 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
284 \item[\constd{SOCK\_STREAM}] Provvede un canale di trasmissione dati
285 bidirezionale, sequenziale e affidabile. Opera su una connessione con un
286 altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
287 byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
288 dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
289 urgenti (o \textit{out-of-band}, vedi sez.~\ref{sec:TCP_urgent_data}).
290 \item[\constd{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
291 (\textit{datagram}) di lunghezza massima prefissata, indirizzati
292 singolarmente. Non esiste una connessione e la trasmissione è effettuata in
293 maniera non affidabile.
294 \item[\constd{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
295 bidirezionale, sequenziale e affidabile. Opera su una connessione con un
296 altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
297 massima fissata, e devono essere letti integralmente da ciascuna chiamata a
299 \item[\constd{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
300 rete e alle varie interfacce. I normali programmi di comunicazione non
301 devono usarlo, è riservato all'uso di sistema.
302 \item[\constd{SOCK\_RDM}] Provvede un canale di trasmissione di dati
303 affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
304 \item[\constd{SOCK\_PACKET}] Obsoleto, non deve essere più usato (e pertanto
305 non ne parleremo ulteriormente).
308 A partire dal kernel 2.6.27 l'argomento \param{type} della funzione
309 \func{socket} assume un significato ulteriore perché può essere utlizzato per
310 impostare dei flag relativi alle caratteristiche generali del \textit{socket}
311 non strettamente attinenti all'indicazione del tipo secondo i valori appena
312 illustrati. Essi infatti possono essere combinati con un OR aritmetico delle
314 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
315 \item[\constd{SOCK\_CLOEXEC}] imposta il flag di \textit{close-on-exec} sul
316 file descriptor del socket, ottenendo lo stesso effetto del flag
317 \const{O\_CLOEXEC} di \func{open} (vedi tab.~\ref{tab:open_operation_flag}),
318 di cui costituisce l'analogo.
320 \item[\constd{SOCK\_NONBLOCK}] crea il socket in modalità non-bloccante, con
321 effetti identici ad una successiva chiamata a \func{fcntl} per impostare il
322 flag di \const{O\_NONBLOCK} sul file descriptor (si faccia di nuovo
323 riferimenti al significato di quest'ultimo come spiegato in
324 tab.~\ref{tab:open_operation_flag}).
328 Si tenga presente inoltre che non tutte le combinazioni fra una famiglia di
329 protocolli e un tipo di socket sono valide, in quanto non è detto che in una
330 famiglia esista un protocollo per ciascuno dei diversi stili di comunicazione
336 \begin{tabular}{|l|c|c|c|c|c|}
338 \multicolumn{1}{|c|}{\textbf{Famiglia}}&
339 \multicolumn{5}{|c|}{\textbf{Tipo}}\\
342 &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}&
343 \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\
345 \const{PF\_LOCAL} & si & si & & & \\
347 % \const{PF\_UNIX}&\multicolumn{5}{|l|}{sinonimo di \const{PF\_LOCAL}.}\\
349 \const{PF\_INET} & TCP & UDP & IPv4 & & \\
351 \const{PF\_INET6} & TCP & UDP & IPv6 & & \\
353 \const{PF\_IPX} & & & & & \\
355 \const{PF\_NETLINK} & & si & si & & \\
357 \const{PF\_X25} & & & & & si \\
359 \const{PF\_AX25} & & & & & \\
361 \const{PF\_ATMPVC} & & & & & \\
363 \const{PF\_APPLETALK} & & si & si & & \\
365 \const{PF\_PACKET} & & si & si & & \\
368 \caption{Combinazioni valide di dominio e tipo di protocollo per la
369 funzione \func{socket}.}
370 \label{tab:sock_sock_valid_combinations}
373 In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
374 valide possibili per le principali famiglie di protocolli. Per ogni
375 combinazione valida si è indicato il tipo di protocollo, o la parola
376 \textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
377 sono lasciate vuote le caselle per le combinazioni non supportate.
380 \section{Le strutture degli indirizzi dei socket}
381 \label{sec:sock_sockaddr}
383 Come si è visto nella creazione di un socket non si specifica nulla oltre al
384 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
385 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
386 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
389 Gli indirizzi infatti vengono specificati attraverso apposite strutture che
390 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
391 la comunicazione viene effettivamente realizzata. Ogni famiglia di protocolli
392 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
393 sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
394 iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
395 identificati dal suffisso finale, aggiunto al nome precedente.
398 \subsection{La struttura generica}
399 \label{sec:sock_sa_gen}
401 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
402 attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
403 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
404 nelle varie famiglie di protocolli; questo pone il problema di come passare
405 questi puntatori, il C moderno risolve questo problema coi i puntatori
406 generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
407 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
408 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
409 è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
412 \footnotesize \centering
413 \begin{minipage}[c]{0.80\textwidth}
414 \includestruct{listati/sockaddr.h}
416 \caption{La struttura generica degli indirizzi dei socket
418 \label{fig:sock_sa_gen_struct}
421 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
422 prototipo un puntatore a questa struttura; per questo motivo quando si
423 invocano dette funzioni passando l'indirizzo di un protocollo specifico
424 occorrerà eseguire una conversione del relativo puntatore.
426 I tipi di dati che compongono la struttura sono stabiliti dallo standard
427 POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
428 rispettivi file di include in cui sono definiti; la struttura è invece
429 definita nell'include file \headfile{sys/socket.h}.
434 \begin{tabular}{|l|l|l|}
436 \multicolumn{1}{|c|}{\textbf{Tipo}}&
437 \multicolumn{1}{|c|}{\textbf{Descrizione}}&
438 \multicolumn{1}{|c|}{\textbf{Header}} \\
441 \typed{int8\_t} & intero a 8 bit con segno & \headfile{sys/types.h}\\
442 \typed{uint8\_t} & intero a 8 bit senza segno & \headfile{sys/types.h}\\
443 \typed{int16\_t} & intero a 16 bit con segno & \headfile{sys/types.h}\\
444 \typed{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\
445 \typed{int32\_t} & intero a 32 bit con segno & \headfile{sys/types.h}\\
446 \typed{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\
448 \typed{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\
449 \typed{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
450 un socket& \headfile{sys/socket.h}\\
452 \typed{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
453 \headfile{netinet/in.h}\\
454 \typed{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
455 \headfile{netinet/in.h}\\
458 \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
459 stabilito dallo standard POSIX.1g.}
460 \label{tab:sock_data_types}
463 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
464 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
465 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
466 non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
467 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
469 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
470 di fare da riferimento per il casting, per il kernel le cose sono un po'
471 diverse, in quanto esso usa il puntatore per recuperare il campo
472 \var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
473 indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
474 sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
475 è stato mantenuto l'uso di questa struttura.
478 \subsection{La struttura degli indirizzi IPv4}
479 \label{sec:sock_sa_ipv4}
481 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
482 attraverso internet; la struttura per gli indirizzi per un socket internet (se
483 si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
484 \headfiled{netinet/in.h} ed ha la forma mostrata in
485 fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
488 \footnotesize\centering
489 \begin{minipage}[c]{0.80\textwidth}
490 \includestruct{listati/sockaddr_in.h}
492 \caption{La struttura \structd{sockaddr\_in} degli indirizzi dei socket
493 internet (IPv4) e la struttura \structd{in\_addr} degli indirizzi IPv4.}
494 \label{fig:sock_sa_ipv4_struct}
497 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
498 internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
499 dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}). Il
500 protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
501 protocolli di livello superiore come TCP e UDP. Questa struttura però viene
502 usata anche per i socket RAW che accedono direttamente al livello di IP, nel
503 qual caso il numero della porta viene impostato al numero di protocollo.
505 Il membro \var{sin\_family} deve essere sempre impostato a \constd{AF\_INET},
506 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
507 specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
508 chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
509 soltanto processi con i privilegi di amministratore (con \ids{UID} effettivo
510 uguale a zero) o con la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}
511 possono usare la funzione \func{bind} (che vedremo in
512 sez.~\ref{sec:TCP_func_bind}) su queste porte.
514 Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
515 come struttura (un resto di una implementazione precedente in cui questa era
516 una \dirct{union} usata per accedere alle diverse classi di indirizzi) che
517 direttamente come intero. In \headfile{netinet/in.h} vengono definite anche
518 alcune costanti che identificano alcuni indirizzi speciali, riportati in
519 tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
521 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
522 essere specificati in quello che viene chiamato \textit{network order}, cioè
523 con i bit ordinati in formato \textit{big endian} (vedi
524 sez.~\ref{sec:endianness}), questo comporta la necessità di usare apposite
525 funzioni di conversione per mantenere la portabilità del codice (vedi
526 sez.~\ref{sec:sock_addr_func} per i dettagli del problema e le relative
530 \subsection{La struttura degli indirizzi IPv6}
531 \label{sec:sock_sa_ipv6}
533 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
534 sostanzialmente identici ai precedenti; la parte in cui si trovano
535 praticamente tutte le differenze fra i due socket è quella della struttura
536 degli indirizzi; la sua definizione, presa da \headfile{netinet/in.h}, è
537 riportata in fig.~\ref{fig:sock_sa_ipv6_struct}.
540 \footnotesize \centering
541 \begin{minipage}[c]{0.80\textwidth}
542 \includestruct{listati/sockaddr_in6.h}
544 \caption{La struttura \structd{sockaddr\_in6} degli indirizzi dei socket
545 IPv6 e la struttura \structd{in6\_addr} degli indirizzi IPv6.}
546 \label{fig:sock_sa_ipv6_struct}
549 Il campo \var{sin6\_family} deve essere sempre impostato ad \constd{AF\_INET6},
550 il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
551 il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
552 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
553 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
554 specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed
555 il loro uso è sperimentale.
557 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
558 espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
559 campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni
560 riguardanti il \textit{multicasting}. Si noti infine che
561 \struct{sockaddr\_in6} ha una dimensione maggiore della struttura
562 \struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi
563 occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
564 di contenere i dati nelle dimensioni di quest'ultima.
567 \subsection{La struttura degli indirizzi locali}
568 \label{sec:sock_sa_local}
570 I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
571 comunicazione fra processi che stanno sulla stessa macchina (per questo
572 vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
573 hanno la caratteristica ulteriore di poter essere creati anche in maniera
574 anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
575 sez.~\ref{sec:ipc_socketpair}). Quando però si vuole fare riferimento
576 esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
577 di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
578 fig.~\ref{fig:sock_sa_local_struct}.
581 \footnotesize \centering
582 \begin{minipage}[c]{0.80\textwidth}
583 \includestruct{listati/sockaddr_un.h}
585 \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
586 locali (detti anche \textit{unix domain}) definita in
587 \headfiled{sys/un.h}.}
588 \label{fig:sock_sa_local_struct}
591 In questo caso il campo \var{sun\_family} deve essere \constd{AF\_UNIX}, mentre
592 il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
593 può essere un file (di tipo socket) nel filesystem o una stringa univoca
594 (mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
595 specificato come una stringa (terminata da uno zero) corrispondente al
596 \textit{pathname} del file; nel secondo invece \var{sun\_path} inizia con uno
597 zero e vengono usati come nome i restanti byte come stringa, senza
601 \subsection{La struttura degli indirizzi AppleTalk}
602 \label{sec:sock_sa_appletalk}
604 I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
605 \file{netatalk} per implementare la comunicazione secondo il protocollo
606 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
607 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
608 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
609 opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
610 questo argomento principalmente per mostrare l'uso di un protocollo
613 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
614 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
615 \func{socket} deve essere nullo. È altresì possibile usare i socket raw
616 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
617 per \param{protocol} è \constd{ATPROTO\_DDP}.
619 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
620 \struct{sockaddr\_atalk}, la cui definizione è riportata in
621 fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
622 il file \headfiled{netatalk/at.h}.
625 \footnotesize \centering
626 \begin{minipage}[c]{0.80\textwidth}
627 \includestruct{listati/sockaddr_atalk.h}
629 \caption{La struttura \structd{sockaddr\_atalk} degli indirizzi dei socket
630 AppleTalk, e la struttura \structd{at\_addr} degli indirizzi AppleTalk.}
631 \label{fig:sock_sa_atalk_struct}
634 Il campo \var{sat\_family} deve essere sempre \constd{AF\_APPLETALK}, mentre
635 il campo \var{sat\_port} specifica la porta che identifica i vari
636 servizi. Valori inferiori a 129 sono usati per le \textsl{porte riservate}, e
637 possono essere usati solo da processi con i privilegi di amministratore o con
638 la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è
639 specificato nella struttura \var{sat\_addr}, e deve essere in \textit{network
640 order} (vedi sez.~\ref{sec:endianness}); esso è composto da un parte di rete
641 data dal campo \var{s\_net}, che può assumere il valore \constd{AT\_ANYNET},
642 che indica una rete generica e vale anche per indicare la rete su cui si è, il
643 singolo nodo è indicato da \var{s\_node}, e può prendere il valore generico
644 \constd{AT\_ANYNODE} che indica anche il nodo corrente, ed il valore
645 \constd{ATADDR\_BCAST} che indica tutti i nodi della rete.
648 \subsection{La struttura degli indirizzi dei \textit{packet socket}}
649 \label{sec:sock_sa_packet}
651 I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
652 un'interfaccia specifica di Linux per inviare e ricevere pacchetti
653 direttamente su un'interfaccia di rete, senza passare per le funzioni di
654 gestione dei protocolli di livello superiore. In questo modo è possibile
655 implementare dei protocolli in user space, agendo direttamente sul livello
656 fisico. In genere comunque si preferisce usare la libreria
657 \file{pcap},\footnote{la libreria è mantenuta insieme al comando
658 \cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
659 progetto \url{http://www.tcpdump.org/}.} che assicura la portabilità su
660 altre piattaforme, anche se con funzionalità ridotte.
662 Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
663 Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
664 collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
665 del dispositivo e viceversa. In questo modo, in fase di trasmissione, il
666 contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
667 fornito dall'utente. In fase di ricezione invece tutto il contenuto del
668 pacchetto viene passato inalterato sul socket, anche se il kernel analizza
669 comunque il pacchetto, riempiendo gli opportuni campi della struttura
670 \struct{sockaddr\_ll} ad esso associata.
672 Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
673 livello di rete. In questo caso in fase di ricezione l'intestazione del
674 protocollo di collegamento viene rimossa prima di passare il resto del
675 pacchetto all'utente, mentre in fase di trasmissione viene creata una
676 opportuna intestazione per il protocollo a livello di collegamento
677 utilizzato, usando le informazioni necessarie che devono essere specificate
678 sempre con una struttura \struct{sockaddr\_ll}.
680 Nella creazione di un \textit{packet socket} il valore dell'argomento
681 \param{protocol} di \func{socket} serve a specificare, in \textit{network
682 order}, il numero identificativo del protocollo di collegamento si vuole
683 utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
684 quelli disponibili in Linux sono accessibili attraverso opportune costanti
685 simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
686 speciale \constd{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
687 pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
688 di questi socket è una operazione privilegiata e può essere effettuati solo da
689 un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o
690 con la \textit{capability} \const{CAP\_NET\_RAW}.
692 Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
693 specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
694 provengono; se si vuole limitare il passaggio ad una interfaccia specifica
695 occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
698 \footnotesize \centering
699 \begin{minipage}[c]{\textwidth}
700 \includestruct{listati/sockaddr_ll.h}
702 \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
703 \textit{packet socket}.}
704 \label{fig:sock_sa_packet_struct}
707 Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
708 \struct{sockaddr\_ll}, e la sua definizione è riportata in
709 fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
710 leggermente diverso rispetto a quanto visto finora per gli altri tipi di
711 socket. Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
712 scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
713 specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
714 tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
715 al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
716 entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
719 Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
720 \constd{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
721 e deve essere indicato in \textit{network order}, facendo uso delle costanti
722 simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
723 l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
724 stesso tipo (se ad esempio si hanno più schede ethernet), permette di
725 selezionare quella con cui si vuole operare (un valore nullo indica qualunque
726 interfaccia). Questi sono i due soli campi che devono essere specificati
727 quando si vuole selezionare una interfaccia specifica, usando questa struttura
728 con la funzione \func{bind}.
730 I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
731 l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
732 relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
733 collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il
734 MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
735 ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
736 pacchetti, in questo caso tutti gli altri campi devono essere nulli.
738 Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
739 \file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
740 pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
741 senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
742 seguenti valori: \constd{PACKET\_HOST} per un pacchetto indirizzato alla
743 macchina ricevente, \constd{PACKET\_BROADCAST} per un pacchetto di
744 \textit{broadcast}, \constd{PACKET\_MULTICAST} per un pacchetto inviato ad un
745 indirizzo fisico di \textit{multicast}, \constd{PACKET\_OTHERHOST} per un
746 pacchetto inviato ad un'altra stazione (e ricevuto su un'interfaccia in modo
747 promiscuo), \constd{PACKET\_OUTGOING} per un pacchetto originato dalla propria
748 macchina che torna indietro sul socket.
751 Si tenga presente infine che in fase di ricezione, anche se si richiede il
752 troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
753 \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
754 lunghezza effettiva del pacchetto così come arrivato sulla linea.
756 %% \subsection{La struttura degli indirizzi DECnet}
757 %% \label{sec:sock_sa_decnet}
759 %% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
760 %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
761 %% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
762 %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
766 % TODO: trattare i socket RDS, vedi documentazione del kernel, file
767 % Documentation/networking/rds.txt
771 \section{Le funzioni di conversione degli indirizzi}
772 \label{sec:sock_addr_func}
774 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
775 indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
776 indirizzi e i numeri di porta usati nella rete devono essere forniti nel
777 cosiddetto \textit{network order}, che corrisponde al formato \textit{big
778 endian}, anche quando la proprio macchina non usa questo formati, cosa che
779 può comportare la necessità di eseguire delle conversioni.
782 \subsection{Le funzioni per il riordinamento}
783 \label{sec:sock_func_ord}
785 Come già visto in sez.~\ref{sec:endianness} il problema connesso
786 all'\textit{endianness} è che quando si passano dei dati da un tipo di
787 architettura all'altra i dati vengono interpretati in maniera diversa, e ad
788 esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è
789 suddiviso scambiati di posto. Per questo motivo si usano delle funzioni di
790 conversione che servono a tener conto automaticamente della possibile
791 differenza fra l'ordinamento usato sul computer e quello che viene usato nelle
792 trasmissione sulla rete; queste funzioni sono \funcd{htonl}, \funcd{htons},
793 \funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono:
795 \headdecl{netinet/in.h}
796 \funcdecl{unsigned long int htonl(unsigned long int hostlong)}
797 Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
800 \funcdecl{unsigned short int htons(unsigned short int hostshort)}
801 Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
804 \funcdecl{unsigned long int ntohl(unsigned long int netlong)}
805 Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
808 \funcdecl{unsigned sort int ntohs(unsigned short int netshort)}
809 Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
812 \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non
816 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
817 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
818 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
819 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
820 indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
823 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
824 macchina che si sta usando abbia una architettura \textit{big endian} queste
825 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
826 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
827 assicurare la portabilità del codice su tutte le architetture.
830 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
832 \label{sec:sock_func_ipv4}
834 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
835 binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
836 dei numeri IP che si usa normalmente.
838 Le prime tre funzioni di manipolazione riguardano la conversione degli
839 indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
840 cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
841 \texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
842 order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
843 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
844 \funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
846 \headdecl{arpa/inet.h}
848 \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
849 dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
851 \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
852 la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
854 \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
855 Converte un indirizzo IP in una stringa \textit{dotted decimal}.
857 \bodydesc{Tutte queste le funzioni non generano codice di errore.}
860 La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
861 network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
862 nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
863 un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
864 tipicamente sono trentadue bit a uno. Questo però comporta che la stringa
865 \texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
866 con questa funzione; per questo motivo essa è generalmente deprecata in favore
867 di \func{inet\_aton}.
869 La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
870 nell'indirizzo binario che viene memorizzato nell'opportuna struttura
871 \struct{in\_addr} (si veda fig.~\ref{fig:sock_sa_ipv4_struct}) situata
872 all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
873 modo da poterla usare direttamente con il puntatore usato per passare la
874 struttura degli indirizzi). La funzione restituisce un valore diverso da zero
875 se l'indirizzo è valido e la conversione ha successo e 0 in caso contrario.
876 Se usata con \param{dest} inizializzato a \val{NULL} effettua la validazione
879 L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
880 dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
881 alla stringa che contiene l'espressione in formato dotted decimal. Si deve
882 tenere presente che la stringa risiede in memoria statica, per cui questa
883 funzione non è rientrante.
886 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
887 \label{sec:sock_conv_func_gen}
889 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
890 motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
891 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
892 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
893 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
896 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
897 indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
898 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
899 indirizzo; il suo prototipo è:
900 \begin{prototype}{sys/socket.h}
901 {int inet\_pton(int af, const char *src, void *addr\_ptr)}
903 Converte l'indirizzo espresso tramite una stringa nel valore numerico.
905 \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
906 una famiglia di indirizzi non valida, con \var{errno} che assume il valore
907 \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
908 indirizzo valido, ed un valore positivo in caso di successo.}
911 La funzione converte la stringa indicata tramite \param{src} nel valore
912 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
913 memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
914 restituisce un valore positivo in caso di successo, nullo se la stringa non
915 rappresenta un indirizzo valido, e negativo se \param{af} specifica una
916 famiglia di indirizzi non valida.
918 La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
919 indirizzo in una stringa; il suo prototipo è:
920 \begin{prototype}{sys/socket.h}
921 {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
922 Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
924 \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
925 convertita in caso di successo e \val{NULL} in caso di fallimento, nel
926 qual caso \var{errno} assume i valori:
928 \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
929 dell'indirizzo eccedono la lunghezza specificata da \param{len}.
930 \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
935 La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
936 in una stringa che viene copiata nel buffer puntato dall'indirizzo
937 \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
938 essere almeno \constd{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
939 \constd{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
940 comunque venire specificata attraverso il parametro \param{len}.
942 Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
943 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
944 per IPv6), che devono essere precedentemente allocate e passate attraverso il
945 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
946 può essere nullo e deve essere allocato precedentemente.
948 Il formato usato per gli indirizzi in formato di presentazione è la notazione
949 \textit{dotted decimal} per IPv4 e quello descritto in
950 sez.~\ref{sec:IP_ipv6_notation} per IPv6.
957 % LocalWords: socket sez cap BSD SVr XTI Transport Interface TCP stream UDP PF
958 % LocalWords: datagram broadcast descriptor sys int domain type protocol errno
959 % LocalWords: EPROTONOSUPPORT ENFILE kernel EMFILE EACCES EINVAL ENOBUFS raw
960 % LocalWords: ENOMEM table family AF address name glibc UNSPEC LOCAL Local IPv
961 % LocalWords: communication INET protocols ip AX Amateur IPX Novell APPLETALK
962 % LocalWords: Appletalk ddp NETROM NetROM Multiprotocol ATMPVC Access to ATM
963 % LocalWords: PVCs ITU ipv PLP DECnet Reserved for project NETBEUI LLC KEY key
964 % LocalWords: SECURITY Security callback NETLINK interface device netlink Low
965 % LocalWords: PACKET level packet ASH Ash ECONET Acorn Econet ATMSVC SVCs SNA
966 % LocalWords: IRDA PPPOX PPPoX WANPIPE Wanpipe BLUETOOTH Bluetooth POSIX bits
967 % LocalWords: dall'header tab SOCK capabilities capability styles DGRAM read
968 % LocalWords: SEQPACKET RDM sockaddr reference void fig Header uint socklen at
969 % LocalWords: addr netinet port len Stevens unsigned short casting nell'header
970 % LocalWords: BIND SERVICE bind union order big endian flowinfo dell'header ll
971 % LocalWords: multicast multicasting local socketpair sun path filesystem AARP
972 % LocalWords: pathname AppleTalk netatalk personal Apple ATPROTO atalk sat if
973 % LocalWords: ANYNET node ANYNODE ATADDR BCAST pcap IEEE linux ether ETH ALL
974 % LocalWords: sll ifindex ethernet halen MAC hatype ARP arp pkttype HOST recv
975 % LocalWords: OTHERHOST OUTGOING recvfrom recvmsg endianness little endtest Mac
976 % LocalWords: Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
977 % LocalWords: htons ntohl ntohs long hostlong hostshort netlong
978 % LocalWords: sort netshort host inet aton ntoa dotted decimal const char src
979 % LocalWords: strptr struct dest addrptr INADDR NULL pton ntop presentation af
980 % LocalWords: numeric EAFNOSUPPORT size ENOSPC ENOAFSUPPORT ADDRSTRLEN ROUTE
981 % LocalWords: of tcpdump page
986 %%% TeX-master: "gapil"