3 %% Copyright (C) 2000-2010 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
12 \chapter{Introduzione ai socket}
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{Una panoramica}
26 \label{sec:sock_overview}
28 Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di
29 quali sono i concetti fondamentali da tenere presente quando si ha a che fare
32 \index{socket!definizione|(}
34 \subsection{I \textit{socket}}
35 \label{sec:sock_socket_def}
37 I \textit{socket}\footnote{una traduzione letterale potrebbe essere
38 \textsl{presa}, ma essendo universalmente noti come \textit{socket}
39 utilizzeremo sempre la parola inglese.} sono uno dei principali meccanismi
40 di comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati
41 in sez.~\ref{sec:ipc_socketpair}, fra i vari meccanismi di intercomunicazione
42 fra processi. Un socket costituisce in sostanza un canale di comunicazione fra
43 due processi su cui si possono leggere e scrivere dati analogo a quello di una
44 pipe (vedi sez.~\ref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
45 meccanismi esaminati nel capitolo cap.~\ref{cha:IPC}, i socket non sono
46 limitati alla comunicazione fra processi che girano sulla stessa macchina, ma
47 possono realizzare la comunicazione anche attraverso la rete.
49 Quella dei socket costituisce infatti la principale interfaccia usata nella
50 programmazione di rete. La loro origine risale al 1983, quando furono
51 introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
52 piccole modifiche, negli anni successivi. Benché siano state sviluppate
53 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
54 Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
55 di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
57 La flessibilità e la genericità dell'interfaccia inoltre consente di
58 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
59 solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
60 di cui tratteremo in maniera più estesa.
63 \subsection{Concetti base}
66 Per capire il funzionamento dei socket occorre avere presente il funzionamento
67 dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
68 tutto generale e benché le problematiche (e quindi le modalità di risolvere i
69 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
70 usato, le funzioni da usare restano le stesse.
72 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
73 inutile, in quanto il comportamento di quest'ultima e le problematiche da
74 affrontare cambiano radicalmente a seconda dello \textsl{stile} di
75 comunicazione usato. La scelta di questo stile va infatti ad incidere sulla
76 semantica che verrà utilizzata a livello utente per gestire la comunicazione
77 (su come inviare e ricevere i dati) e sul comportamento effettivo delle
80 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
81 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
82 comunicazione considerano i dati come una sequenza continua di byte, in quello
83 che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
84 altri invece li raggruppano in \textsl{pacchetti} (in inglese
85 \textit{datagram}) che vengono inviati in blocchi separati.
87 Un altro esempio di stile concerne la possibilità che la comunicazione possa o
88 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
89 inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
91 Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
92 avviene, in certi casi essa può essere condotta con una connessione diretta
93 con un solo corrispondente, come per una telefonata; altri casi possono
94 prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
95 ogni pacchetto, altri ancora una comunicazione \itindex{broadcast}
96 \textit{broadcast} come per la radio, in cui i pacchetti vengono emessi su
97 appositi ``\textsl{canali}'' dove chiunque si collega possa riceverli.
99 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
100 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
101 gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
102 dovranno essere opportunamente trattati, ecc.
105 \section{La creazione di un socket}
106 \label{sec:sock_creation}
108 Come accennato l'interfaccia dei socket è estremamente flessibile e permette
109 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
110 in questa sezione vedremo come è possibile creare un socket e come specificare
111 il tipo di comunicazione che esso deve utilizzare.
113 \subsection{La funzione \func{socket}}
114 \label{sec:sock_socket}
116 La creazione di un socket avviene attraverso l'uso della funzione
117 \funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
118 tutto analogo a quelli che si ottengono per i file di dati e le pipe,
119 descritti in sez.~\ref{sec:file_fd}.} che serve come riferimento al socket;
121 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
125 \bodydesc{La funzione restituisce un intero positivo in caso di successo, e
126 -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
129 \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
130 non sono supportati nel dominio.
131 \item[\errcode{ENFILE}] il kernel non ha memoria sufficiente a creare una
132 nuova struttura per il socket.
133 \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
134 \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
135 dominio o con il protocollo specificato.
136 \item[\errcode{EINVAL}] protocollo sconosciuto o dominio non disponibile.
137 \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
138 (può essere anche \errval{ENOMEM}).
140 inoltre, a seconda del protocollo usato, potranno essere generati altri
141 errori, che sono riportati nelle relative pagine di manuale.}
144 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
145 (definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
146 protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
147 come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
148 \param{protocol} il protocollo; in genere quest'ultimo è indicato
149 implicitamente dal tipo di socket, per cui di norma questo valore viene messo
150 a zero (con l'eccezione dei \textit{raw socket}).
152 Si noti che la creazione del socket si limita ad allocare le opportune
153 strutture nel kernel (sostanzialmente una voce nella \itindex{file~table}
154 \textit{file table}) e non comporta nulla riguardo all'indicazione degli
155 indirizzi remoti o locali attraverso i quali si vuole effettuare la
158 \subsection{Il dominio dei socket}
159 \label{sec:sock_domain}
161 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
162 tipi di socket, che vengono classificati raggruppandoli in quelli che si
163 chiamano \textsl{domini}. La scelta di un dominio equivale in sostanza alla
164 scelta di una famiglia di protocolli, e viene effettuata attraverso
165 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
166 suo nome simbolico che convenzionalmente è indicato da una costante che inizia
167 per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
168 cui si indicano i domini.
170 A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
171 associato ad una costante, che inizia invece per \texttt{AF\_} (da
172 \textit{address family}) che identifica il formato degli indirizzi usati in
173 quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
174 anche come \textit{name space},\footnote{nome che invece il manuale delle
175 \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
176 identificano il formato degli indirizzi usati in quel dominio per identificare
177 i capi della comunicazione.
182 \begin{tabular}[c]{|l|l|l|l|}
184 \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
187 \const{PF\_UNSPEC} & 0& Non specificato & \\
188 \const{PF\_LOCAL} & 1& Local communication & unix(7) \\
189 \const{PF\_UNIX}, \const{PF\_FILE}&1&Sinonimi di \const{PF\_LOCAL}& \\
190 \const{PF\_INET} & 2& IPv4 Internet protocols & ip(7) \\
191 \const{PF\_AX25} & 3& Amateur radio AX.25 protocol & \\
192 \const{PF\_IPX} & 4& IPX - Novell protocols & \\
193 \const{PF\_APPLETALK}& 5& Appletalk & ddp(7) \\
194 \const{PF\_NETROM} & 6& Amateur radio NetROM & \\
195 \const{PF\_BRIDGE} & 7& Multiprotocol bridge & \\
196 \const{PF\_ATMPVC} & 8& Access to raw ATM PVCs & \\
197 \const{PF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\
198 \const{PF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\
199 \const{PF\_ROSE} &11& Amateur Radio X.25 PLP & \\
200 \const{PF\_DECnet} &12& Reserved for DECnet project & \\
201 \const{PF\_NETBEUI} &13& Reserved for 802.2LLC project & \\
202 \const{PF\_SECURITY} &14& Security callback pseudo AF & \\
203 \const{PF\_KEY} &15& PF\_KEY key management API & \\
204 \const{PF\_NETLINK} &16& Kernel user interface device & netlink(7) \\
205 \const{PF\_ROUTE} &16& Sinonimo di \const{PF\_NETLINK} emula BSD.&\\
206 \const{PF\_PACKET} &17& Low level packet interface & packet(7) \\
207 \const{PF\_ASH} &18& Ash & \\
208 \const{PF\_ECONET} &19& Acorn Econet & \\
209 \const{PF\_ATMSVC} &20& ATM SVCs & \\
210 \const{PF\_SNA} &22& Linux SNA Project & \\
211 \const{PF\_IRDA} &23& IRDA socket & \\
212 \const{PF\_PPPOX} &24& PPPoX socket & \\
213 \const{PF\_WANPIPE} &25& Wanpipe API socket & \\
214 \const{PF\_LLC} &26& Linux LLC & \\
215 \const{PF\_BLUETOOTH}&31& Bluetooth socket & \\
218 \caption{Famiglie di protocolli definiti in Linux.}
219 \label{tab:net_pf_names}
222 % TODO aggiungere PF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25
224 L'idea alla base della distinzione fra questi due insiemi di costanti era che
225 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
226 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
227 il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
228 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
229 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
230 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
231 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
232 il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
233 e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
236 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
237 indirizzi, sono definiti dall'header \texttt{socket.h}. Un elenco delle
238 famiglie di protocolli disponibili in Linux è riportato in
239 tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
240 definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
241 compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
242 viene definita anche una costante \const{PF\_MAX} che indica il valore
243 massimo associabile ad un dominio (nel caso il suo valore 32).}
245 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
246 dall'utente generico, ad esempio in generale tutti i socket di tipo
247 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
248 di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
249 \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
252 \subsection{Il tipo di socket}
253 \label{sec:sock_type}
255 La scelta di un dominio non comporta però la scelta dello stile di
256 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
257 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
258 socket permette di scegliere lo stile di comunicazione indicando il tipo di
259 socket con l'argomento \param{type} di \func{socket}. Linux mette a
260 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
261 della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
262 seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
263 tre tipi, Linux supporta anche gli altri, come si può verificare nel file
264 \texttt{include/linux/net.h} dei sorgenti del kernel.}
266 \begin{basedescript}{\desclabelwidth{2.9cm}\desclabelstyle{\nextlinelabel}}
267 \item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati
268 bidirezionale, sequenziale e affidabile. Opera su una connessione con un
269 altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
270 byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
271 dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
272 urgenti (o \itindex{out-of-band} \textit{out-of-band}, vedi
273 sez.~\ref{sec:TCP_urgent_data}).
274 \item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
275 (\textit{datagram}) di lunghezza massima prefissata, indirizzati
276 singolarmente. Non esiste una connessione e la trasmissione è effettuata in
277 maniera non affidabile.
278 \item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
279 bidirezionale, sequenziale e affidabile. Opera su una connessione con un
280 altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
281 massima fissata, e devono essere letti integralmente da ciascuna chiamata a
283 \item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
284 rete e alle varie interfacce. I normali programmi di comunicazione non
285 devono usarlo, è riservato all'uso di sistema.
286 \item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
287 affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
288 \item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
289 pertanto non ne parleremo ulteriormente.}
292 Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
293 e un tipo di socket sono valide, in quanto non è detto che in una famiglia
294 esista un protocollo per ciascuno dei diversi stili di comunicazione appena
300 \begin{tabular}{|l|c|c|c|c|c|}
302 \multicolumn{1}{|c|}{\textbf{Famiglia}}&
303 \multicolumn{5}{|c|}{\textbf{Tipo}}\\
306 &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}&
307 \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\
309 \const{PF\_LOCAL} & si & si & & & \\
311 % \const{PF\_UNIX}&\multicolumn{5}{|l|}{sinonimo di \const{PF\_LOCAL}.}\\
313 \const{PF\_INET} & TCP & UDP & IPv4 & & \\
315 \const{PF\_INET6} & TCP & UDP & IPv6 & & \\
317 \const{PF\_IPX} & & & & & \\
319 \const{PF\_NETLINK} & & si & si & & \\
321 \const{PF\_X25} & & & & & si \\
323 \const{PF\_AX25} & & & & & \\
325 \const{PF\_ATMPVC} & & & & & \\
327 \const{PF\_APPLETALK} & & si & si & & \\
329 \const{PF\_PACKET} & & si & si & & \\
332 \caption{Combinazioni valide di dominio e tipo di protocollo per la
333 funzione \func{socket}.}
334 \label{tab:sock_sock_valid_combinations}
337 In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
338 valide possibili per le principali famiglie di protocolli. Per ogni
339 combinazione valida si è indicato il tipo di protocollo, o la parola
340 \textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
341 sono lasciate vuote le caselle per le combinazioni non supportate.
344 \section{Le strutture degli indirizzi dei socket}
345 \label{sec:sock_sockaddr}
347 Come si è visto nella creazione di un socket non si specifica nulla oltre al
348 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
349 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
350 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
353 Gli indirizzi infatti vengono specificati attraverso apposite strutture che
354 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
355 la comunicazione viene effettivamente realizzata. Ogni famiglia di protocolli
356 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
357 sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
358 iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
359 identificati dal suffisso finale, aggiunto al nome precedente.
362 \subsection{La struttura generica}
363 \label{sec:sock_sa_gen}
365 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
366 attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
367 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
368 nelle varie famiglie di protocolli; questo pone il problema di come passare
369 questi puntatori, il C moderno risolve questo problema coi i puntatori
370 generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
371 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
372 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
373 è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
376 \footnotesize \centering
377 \begin{minipage}[c]{15cm}
378 \includestruct{listati/sockaddr.h}
380 \caption{La struttura generica degli indirizzi dei socket
382 \label{fig:sock_sa_gen_struct}
385 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
386 prototipo un puntatore a questa struttura; per questo motivo quando si
387 invocano dette funzioni passando l'indirizzo di un protocollo specifico
388 occorrerà eseguire una conversione del relativo puntatore.
390 I tipi di dati che compongono la struttura sono stabiliti dallo standard
391 POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
392 rispettivi file di include in cui sono definiti; la struttura è invece
393 definita nell'include file \file{sys/socket.h}.
398 \begin{tabular}{|l|l|l|}
400 \multicolumn{1}{|c|}{\textbf{Tipo}}&
401 \multicolumn{1}{|c|}{\textbf{Descrizione}}&
402 \multicolumn{1}{|c|}{\textbf{Header}} \\
405 \type{int8\_t} & intero a 8 bit con segno & \file{sys/types.h}\\
406 \type{uint8\_t} & intero a 8 bit senza segno & \file{sys/types.h}\\
407 \type{int16\_t} & intero a 16 bit con segno & \file{sys/types.h}\\
408 \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
409 \type{int32\_t} & intero a 32 bit con segno & \file{sys/types.h}\\
410 \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
412 \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
413 \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
414 un socket& \file{sys/socket.h}\\
416 \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
417 \file{netinet/in.h}\\
418 \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
419 \file{netinet/in.h}\\
422 \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
423 stabilito dallo standard POSIX.1g.}
424 \label{tab:sock_data_types}
427 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
428 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
429 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
430 non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
431 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
433 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
434 di fare da riferimento per il casting, per il kernel le cose sono un po'
435 diverse, in quanto esso usa il puntatore per recuperare il campo
436 \var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
437 indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
438 sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
439 è stato mantenuto l'uso di questa struttura.
442 \subsection{La struttura degli indirizzi IPv4}
443 \label{sec:sock_sa_ipv4}
445 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
446 attraverso internet; la struttura per gli indirizzi per un socket internet (se
447 si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
448 \file{netinet/in.h} ed ha la forma mostrata in
449 fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
452 \footnotesize\centering
453 \begin{minipage}[c]{15cm}
454 \includestruct{listati/sockaddr_in.h}
456 \caption{La struttura \structd{sockaddr\_in} degli indirizzi dei socket
457 internet (IPv4) e la struttura \structd{in\_addr} degli indirizzi IPv4.}
458 \label{fig:sock_sa_ipv4_struct}
461 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
462 internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
463 dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}). Il
464 protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
465 protocolli di livello superiore come TCP e UDP. Questa struttura però viene
466 usata anche per i socket RAW che accedono direttamente al livello di IP, nel
467 qual caso il numero della porta viene impostato al numero di protocollo.
469 Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
470 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
471 specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
472 chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
473 soltanto processi con i privilegi di amministratore (con user-ID effettivo
474 uguale a zero) o con la \itindex{capabilities} \textit{capability}
475 \const{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \func{bind} (che
476 vedremo in sez.~\ref{sec:TCP_func_bind}) su queste porte.
478 Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
479 come struttura (un resto di una implementazione precedente in cui questa era
480 una \direct{union} usata per accedere alle diverse classi di indirizzi) che
481 direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
482 costanti che identificano alcuni indirizzi speciali, riportati in
483 tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
485 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
486 essere specificati in quello che viene chiamato \textit{network order}, cioè
487 con i bit ordinati in formato \textit{big endian}, questo comporta la
488 necessità di usare apposite funzioni di conversione per mantenere la
489 portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
490 problema e le relative soluzioni).
493 \subsection{La struttura degli indirizzi IPv6}
494 \label{sec:sock_sa_ipv6}
496 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
497 sostanzialmente identici ai precedenti; la parte in cui si trovano
498 praticamente tutte le differenze fra i due socket è quella della struttura
499 degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
500 in fig.~\ref{fig:sock_sa_ipv6_struct}.
503 \footnotesize \centering
504 \begin{minipage}[c]{15cm}
505 \includestruct{listati/sockaddr_in6.h}
507 \caption{La struttura \structd{sockaddr\_in6} degli indirizzi dei socket
508 IPv6 e la struttura \structd{in6\_addr} degli indirizzi IPv6.}
509 \label{fig:sock_sa_ipv6_struct}
512 Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
513 il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
514 il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
515 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
516 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
517 specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed
518 il loro uso è sperimentale.
520 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
521 espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
522 campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni
523 riguardanti il \itindex{multicast} \textit{multicasting}. Si noti infine che
524 \struct{sockaddr\_in6} ha una dimensione maggiore della struttura
525 \struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi
526 occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
527 di contenere i dati nelle dimensioni di quest'ultima.
530 \subsection{La struttura degli indirizzi locali}
531 \label{sec:sock_sa_local}
533 I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
534 comunicazione fra processi che stanno sulla stessa macchina (per questo
535 vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
536 hanno la caratteristica ulteriore di poter essere creati anche in maniera
537 anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
538 sez.~\ref{sec:ipc_socketpair}). Quando però si vuole fare riferimento
539 esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
540 di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
541 fig.~\ref{fig:sock_sa_local_struct}.
544 \footnotesize \centering
545 \begin{minipage}[c]{15cm}
546 \includestruct{listati/sockaddr_un.h}
548 \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
549 locali (detti anche \textit{unix domain}) definita in \file{sys/un.h}.}
550 \label{fig:sock_sa_local_struct}
553 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
554 il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
555 può essere un file (di tipo socket) nel filesystem o una stringa univoca
556 (mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
557 specificato come una stringa (terminata da uno zero) corrispondente al
558 \itindex{pathname} \textit{pathname} del file; nel secondo invece
559 \var{sun\_path} inizia con uno zero e vengono usati come nome i restanti byte
560 come stringa, senza terminazione.
563 \subsection{La struttura degli indirizzi AppleTalk}
564 \label{sec:sock_sa_appletalk}
566 I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
567 \file{netatalk} per implementare la comunicazione secondo il protocollo
568 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
569 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
570 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
571 opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
572 questo argomento principalmente per mostrare l'uso di un protocollo
575 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
576 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
577 \func{socket} deve essere nullo. È altresì possibile usare i socket raw
578 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
579 per \param{protocol} è \const{ATPROTO\_DDP}.
581 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
582 \struct{sockaddr\_atalk}, la cui definizione è riportata in
583 fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
584 il file \file{netatalk/at.h}.
587 \footnotesize \centering
588 \begin{minipage}[c]{15cm}
589 \includestruct{listati/sockaddr_atalk.h}
591 \caption{La struttura \structd{sockaddr\_atalk} degli indirizzi dei socket
592 AppleTalk, e la struttura \structd{at\_addr} degli indirizzi AppleTalk.}
593 \label{fig:sock_sa_atalk_struct}
596 Il campo \var{sat\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
597 campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
598 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
599 usati solo da processi con i privilegi di amministratore o con la
600 \itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
601 L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
602 essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
603 composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
604 valore \const{AT\_ANYNET}, che indica una rete generica e vale anche per
605 indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
606 può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
607 corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
611 \subsection{La struttura degli indirizzi dei \textit{packet socket}}
612 \label{sec:sock_sa_packet}
614 I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
615 un'interfaccia specifica di Linux per inviare e ricevere pacchetti
616 direttamente su un'interfaccia di rete, senza passare per le funzioni di
617 gestione dei protocolli di livello superiore. In questo modo è possibile
618 implementare dei protocolli in user space, agendo direttamente sul livello
619 fisico. In genere comunque si preferisce usare la libreria
620 \file{pcap},\footnote{la libreria è mantenuta insieme al comando
621 \cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
622 progetto \href{http://www.tcpdump.org/}{\textsf{http://www.tcpdump.org/}}.}
623 che assicura la portabilità su altre piattaforme, anche se con funzionalità
626 Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
627 Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
628 collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
629 del dispositivo e viceversa. In questo modo, in fase di trasmissione, il
630 contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
631 fornito dall'utente. In fase di ricezione invece tutto il contenuto del
632 pacchetto viene passato inalterato sul socket, anche se il kernel analizza
633 comunque il pacchetto, riempiendo gli opportuni campi della struttura
634 \struct{sockaddr\_ll} ad esso associata.
636 Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
637 livello di rete. In questo caso in fase di ricezione l'intestazione del
638 protocollo di collegamento viene rimossa prima di passare il resto del
639 pacchetto all'utente, mentre in fase di trasmissione viene creata una
640 opportuna intestazione per il protocollo a livello di collegamento
641 utilizzato, usando le informazioni necessarie che devono essere specificate
642 sempre con una struttura \struct{sockaddr\_ll}.
644 Nella creazione di un \textit{packet socket} il valore dell'argomento
645 \param{protocol} di \func{socket} serve a specificare, in \textit{network
646 order}, il numero identificativo del protocollo di collegamento si vuole
647 utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
648 quelli disponibili in Linux sono accessibili attraverso opportune costanti
649 simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
650 speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
651 pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
652 di questi socket è una operazione privilegiata e può essere effettuati solo da
653 un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
654 la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
656 Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
657 specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
658 provengono; se si vuole limitare il passaggio ad una interfaccia specifica
659 occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
662 \footnotesize \centering
663 \begin{minipage}[c]{15cm}
664 \includestruct{listati/sockaddr_ll.h}
666 \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
667 \textit{packet socket}.}
668 \label{fig:sock_sa_packet_struct}
671 Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
672 \struct{sockaddr\_ll}, e la sua definizione è riportata in
673 fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
674 leggermente diverso rispetto a quanto visto finora per gli altri tipi di
675 socket. Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
676 scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
677 specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
678 tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
679 al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
680 entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
683 Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
684 \const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
685 e deve essere indicato in \textit{network order}, facendo uso delle costanti
686 simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
687 l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
688 stesso tipo (se ad esempio si hanno più schede ethernet), permette di
689 selezionare quella con cui si vuole operare (un valore nullo indica qualunque
690 interfaccia). Questi sono i due soli campi che devono essere specificati
691 quando si vuole selezionare una interfaccia specifica, usando questa struttura
692 con la funzione \func{bind}.
694 I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
695 l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
696 relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
697 collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il
698 MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
699 ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
700 pacchetti, in questo caso tutti gli altri campi devono essere nulli.
702 Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
703 \file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
704 pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
705 senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
706 seguenti valori: \const{PACKET\_HOST} per un pacchetto indirizzato alla
707 macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di
708 \itindex{broadcast} \textit{broadcast}, \const{PACKET\_MULTICAST} per un
709 pacchetto inviato ad un indirizzo fisico di \itindex{multicast}
710 \textit{multicast}, \const{PACKET\_OTHERHOST} per un pacchetto inviato ad
711 un'altra stazione (e ricevuto su un'interfaccia in \index{modo~promiscuo} modo
712 promiscuo), \const{PACKET\_OUTGOING} per un pacchetto originato dalla propria
713 macchina che torna indietro sul socket.
716 Si tenga presente infine che in fase di ricezione, anche se si richiede il
717 troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
718 \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
719 lunghezza effettiva del pacchetto così come arrivato sulla linea.
721 %% \subsection{La struttura degli indirizzi DECnet}
722 %% \label{sec:sock_sa_decnet}
724 %% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
725 %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
726 %% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
727 %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
731 % TODO: trattare i socket RDS, vedi documentazione del kernel, file
732 % Documentation/networking/rds.txt
736 \section{Le funzioni di conversione degli indirizzi}
737 \label{sec:sock_addr_func}
739 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
740 indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
741 indirizzi e i numeri di porta usati nella rete devono essere forniti in
742 formato opportuno (il \textit{network order}). Per capire cosa significa tutto
743 ciò occorre introdurre un concetto generale che tornerà utile anche in
747 \subsection{La \textit{endianess}}
748 \label{sec:sock_endianess}
751 La rappresentazione di un numero binario in un computer può essere fatta in
752 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
753 endian} a seconda di come i singoli bit vengono aggregati per formare le
754 variabili intere (ed in genere in diretta corrispondenza a come sono poi in
755 realtà cablati sui bus interni del computer).
759 \includegraphics[height=3cm]{img/endianess}
760 \caption{Schema della disposizione dei dati in memoria a seconda della
762 \label{fig:sock_endianess}
765 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
766 locazione di memoria posta ad un certo indirizzo. Come illustrato in
767 fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
768 in due modi: a partire dal più significativo o a partire dal meno
769 significativo. Così nel primo caso si troverà il byte che contiene i bit più
770 significativi all'indirizzo menzionato e il byte con i bit meno significativi
771 nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
772 dato che si trova per prima la parte più grande. Il caso opposto, in cui si
773 parte dal bit meno significativo è detto per lo stesso motivo \textit{little
776 Si può allora verificare quale tipo di \textit{endianess} usa il proprio
777 computer con un programma elementare che si limita ad assegnare un valore ad
778 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
779 Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
780 allora se lo eseguiamo su un PC otterremo:
782 [piccardi@gont sources]$ ./endtest
789 mentre su di un Mac avremo:
791 piccardi@anarres:~/gapil/sources$ ./endtest
800 La \textit{endianess} di un computer dipende essenzialmente dalla architettura
801 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
802 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
803 formato dei dati contenuti nelle intestazioni dei protocolli di rete è
804 anch'esso \textit{big endian}; altri esempi di uso di questi due diversi
805 formati sono quello del bus PCI, che è \textit{little endian}, o quello del
806 bus VME che è \textit{big endian}.
808 Esistono poi anche dei processori che possono scegliere il tipo di formato
809 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
810 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
811 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
812 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
816 \footnotesize \centering
817 \begin{minipage}[c]{15cm}
818 \includecodesample{listati/endian.c}
821 \caption{La funzione \func{endian}, usata per controllare il tipo di
822 architettura della macchina.}
823 \label{fig:sock_endian_code}
826 Per controllare quale tipo di ordinamento si ha sul proprio computer si è
827 scritta una piccola funzione di controllo, il cui codice è riportato
828 fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
829 l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
830 è \textit{little endian}.
832 Come si vede la funzione è molto semplice, e si limita, una volta assegnato
833 (\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
834 di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
835 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
836 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
837 11}) il valore della seconda assumendo che il primo byte sia quello meno
838 significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
839 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
840 il valore del confronto delle due variabili.
845 \subsection{Le funzioni per il riordinamento}
846 \label{sec:sock_func_ord}
848 Il problema connesso \itindex{endianess} all'endianess è che quando si passano
849 dei dati da un tipo di architettura all'altra i dati vengono interpretati in
850 maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
851 con i due byte in cui è suddiviso scambiati di posto. Per questo motivo si
852 usano delle funzioni di conversione che servono a tener conto automaticamente
853 della possibile differenza fra l'ordinamento usato sul computer e quello che
854 viene usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
855 \funcd{htons}, \funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono:
857 \headdecl{netinet/in.h}
858 \funcdecl{unsigned long int htonl(unsigned long int hostlong)}
859 Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
862 \funcdecl{unsigned short int htons(unsigned short int hostshort)}
863 Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
866 \funcdecl{unsigned long int ntohl(unsigned long int netlong)}
867 Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
870 \funcdecl{unsigned sort int ntohs(unsigned short int netshort)}
871 Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
874 \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non
878 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
879 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
880 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
881 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
882 indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
885 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
886 macchina che si sta usando abbia una architettura \textit{big endian} queste
887 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
888 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
889 assicurare la portabilità del codice su tutte le architetture.
892 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
894 \label{sec:sock_func_ipv4}
896 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
897 binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
898 dei numeri IP che si usa normalmente.
900 Le prime tre funzioni di manipolazione riguardano la conversione degli
901 indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
902 cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
903 \texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
904 order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
905 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
906 \funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
908 \headdecl{arpa/inet.h}
910 \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
911 dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
913 \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
914 la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
916 \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
917 Converte un indirizzo IP in una stringa \textit{dotted decimal}.
919 \bodydesc{Tutte queste le funzioni non generano codice di errore.}
922 La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
923 network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
924 nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
925 un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
926 tipicamente sono trentadue bit a uno. Questo però comporta che la stringa
927 \texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
928 con questa funzione; per questo motivo essa è generalmente deprecata in favore
929 di \func{inet\_aton}.
931 La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
932 nell'indirizzo binario che viene memorizzato nell'opportuna struttura
933 \struct{in\_addr} (si veda fig.~\ref{fig:sock_sa_ipv4_struct}) situata
934 all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
935 modo da poterla usare direttamente con il puntatore usato per passare la
936 struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
937 in caso di fallimento. Se usata con \param{dest} inizializzato a \val{NULL}
938 effettua la validazione dell'indirizzo.
940 L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
941 dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
942 alla stringa che contiene l'espressione in formato dotted decimal. Si deve
943 tenere presente che la stringa risiede in memoria statica, per cui questa
944 funzione non è \index{funzioni!rientranti} rientrante.
947 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
948 \label{sec:sock_conv_func_gen}
950 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
951 motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
952 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
953 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
954 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
957 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
958 indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
959 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
960 indirizzo; il suo prototipo è:
961 \begin{prototype}{sys/socket.h}
962 {int inet\_pton(int af, const char *src, void *addr\_ptr)}
964 Converte l'indirizzo espresso tramite una stringa nel valore numerico.
966 \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
967 una famiglia di indirizzi non valida, con \var{errno} che assume il valore
968 \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
969 indirizzo valido, ed un valore positivo in caso di successo.}
972 La funzione converte la stringa indicata tramite \param{src} nel valore
973 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
974 memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
975 restituisce un valore positivo in caso di successo, nullo se la stringa non
976 rappresenta un indirizzo valido, e negativo se \param{af} specifica una
977 famiglia di indirizzi non valida.
979 La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
980 indirizzo in una stringa; il suo prototipo è:
981 \begin{prototype}{sys/socket.h}
982 {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
983 Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
985 \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
986 convertita in caso di successo e \val{NULL} in caso di fallimento, nel
987 qual caso \var{errno} assume i valori:
989 \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
990 dell'indirizzo eccedono la lunghezza specificata da \param{len}.
991 \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
996 La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
997 in una stringa che viene copiata nel buffer puntato dall'indirizzo
998 \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
999 essere almeno \const{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
1000 \const{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
1001 comunque venire specificata attraverso il parametro \param{len}.
1003 Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
1004 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
1005 per IPv6), che devono essere precedentemente allocate e passate attraverso il
1006 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
1007 può essere nullo e deve essere allocato precedentemente.
1009 Il formato usato per gli indirizzi in formato di presentazione è la notazione
1010 \textit{dotted decimal} per IPv4 e quello descritto in
1011 sez.~\ref{sec:IP_ipv6_notation} per IPv6.
1013 \index{socket!definizione|)}
1021 % LocalWords: socket sez cap BSD SVr XTI Transport Interface TCP stream UDP PF
1022 % LocalWords: datagram broadcast descriptor sys int domain type protocol errno
1023 % LocalWords: EPROTONOSUPPORT ENFILE kernel EMFILE EACCES EINVAL ENOBUFS raw
1024 % LocalWords: ENOMEM table family AF address name glibc UNSPEC LOCAL Local IPv
1025 % LocalWords: communication INET protocols ip AX Amateur IPX Novell APPLETALK
1026 % LocalWords: Appletalk ddp NETROM NetROM Multiprotocol ATMPVC Access to ATM
1027 % LocalWords: PVCs ITU ipv PLP DECnet Reserved for project NETBEUI LLC KEY key
1028 % LocalWords: SECURITY Security callback NETLINK interface device netlink Low
1029 % LocalWords: PACKET level packet ASH Ash ECONET Acorn Econet ATMSVC SVCs SNA
1030 % LocalWords: IRDA PPPOX PPPoX WANPIPE Wanpipe BLUETOOTH Bluetooth POSIX bits
1031 % LocalWords: dall'header tab SOCK capabilities capability styles DGRAM read
1032 % LocalWords: SEQPACKET RDM sockaddr reference void fig Header uint socklen at
1033 % LocalWords: addr netinet port len Stevens unsigned short casting nell'header
1034 % LocalWords: BIND SERVICE bind union order big endian flowinfo dell'header ll
1035 % LocalWords: multicast multicasting local socketpair sun path filesystem AARP
1036 % LocalWords: pathname AppleTalk netatalk personal Apple ATPROTO atalk sat if
1037 % LocalWords: ANYNET node ANYNODE ATADDR BCAST pcap IEEE linux ether ETH ALL
1038 % LocalWords: sll ifindex ethernet halen MAC hatype ARP arp pkttype HOST recv
1039 % LocalWords: OTHERHOST OUTGOING recvfrom recvmsg endianess little endtest Mac
1040 % LocalWords: Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
1041 % LocalWords: all'endianess htons ntohl ntohs long hostlong hostshort netlong
1042 % LocalWords: sort netshort host inet aton ntoa dotted decimal const char src
1043 % LocalWords: strptr struct dest addrptr INADDR NULL pton ntop presentation af
1044 % LocalWords: numeric EAFNOSUPPORT size ENOSPC ENOAFSUPPORT ADDRSTRLEN ROUTE
1045 % LocalWords: of tcpdump page
1048 %%% Local Variables:
1050 %%% TeX-master: "gapil"