3 %% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
11 \chapter{Introduzione ai socket}
12 \label{cha:socket_intro}
14 In questo capitolo inizieremo a spiegare le caratteristiche salienti della
15 principale interfaccia per la programmazione di rete, quella dei
16 \textit{socket}, che, pur essendo nata in ambiente Unix è usata ormai da tutti
19 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
20 come creare un socket e come collegarlo allo specifico protocollo di rete che
21 si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
22 teorica concluderemo il capitolo con un primo esempio di applicazione.
24 \section{Una panoramica}
25 \label{sec:sock_overview}
27 Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di
28 quali sono i concetti fondamentali da tenere presente quando si ha a che fare
33 \subsection{I \textit{socket}}
34 \label{sec:sock_socket_def}
36 I \textit{socket}\footnote{una traduzione letterale potrebbe essere
37 \textsl{presa}, ma essendo universalmente noti come \textit{socket}
38 utilizzeremo sempre la parola inglese.} sono uno dei principali meccanismi
39 di comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati
40 in \secref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione fra
41 processi. Un socket costituisce in sostanza un canale di comunicazione fra due
42 processi su cui si possono leggere e scrivere dati analogo a quello di una
43 pipe (vedi \secref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
44 meccanismi esaminati nel capitolo \capref{cha:IPC}, i socket non sono limitati
45 alla comunicazione fra processi che girano sulla stessa macchina, ma possono
46 realizzare la comunicazione anche attraverso la rete.
48 Quella dei socket costituisce infatti la principale interfaccia usata nella
49 programmazione di rete. La loro origine risale al 1983, quando furono
50 introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
51 piccole modifiche, negli anni successivi. Benché siano state sviluppate
52 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
53 Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
54 di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
56 La flessibilità e la genericità dell'interfaccia inoltre consente di
57 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
58 solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
59 di cui tratteremo in maniera più estesa.
62 \subsection{Concetti base}
65 Per capire il funzionamento dei socket occorre avere presente il funzionamento
66 dei protocolli di rete (vedi \capref{cha:network}), ma l'interfaccia è del
67 tutto generale e benché le problematiche (e quindi le modalità di risolvere i
68 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
69 usato, le funzioni da usare restano le stesse.
71 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
72 inutile, in quanto il comportamento di quest'ultima e le problematiche da
73 affrontare cambiano radicalmente a seconda dello \textsl{stile} di
74 comunicazione usato. La scelta di questo stile va infatti ad incidere sulla
75 semantica che verrà utilizzata a livello utente per gestire la comunicazione
76 (su come inviare e ricevere i dati) e sul comportamento effettivo delle
79 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
80 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
81 comunicazione considerano i dati come una sequenza continua di byte, in quello
82 che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
83 altri invece li raggruppano in \textsl{pacchetti} (in inglese
84 \textit{datagram}) che vengono inviati in blocchi separati.
86 Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
87 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
88 inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
90 Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
91 avviene, in certi casi essa può essere condotta con una connessione diretta
92 con un solo corrispondente, come per una telefonata; altri casi possono
93 prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
94 ogni pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
95 radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove
96 chiunque si collega possa riceverli.
98 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
99 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
100 gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
101 dovranno essere opportunamente trattati, ecc.
104 \section{La creazione di un \textit{socket}}
105 \label{sec:sock_creation}
107 Come accennato l'interfaccia dei socket è estremamente flessibile e permette
108 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
109 in questa sezione vedremo come è possibile creare un socket e come specificare
110 il tipo di comunicazione che esso deve utilizzare.
112 \subsection{La funzione \func{socket}}
113 \label{sec:sock_socket}
115 La creazione di un socket avviene attraverso l'uso della funzione
116 \funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
117 tutto analogo a quelli che si ottengono per i file di dati e le pipe,
118 descritti in \secref{sec:file_fd}.} che serve come riferimento al socket; il
120 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
124 \bodydesc{La funzione restituisce un intero positivo in caso di successo, e
125 -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
128 \item[\errcode{EPROTONOSUPPORT}] Il tipo di socket o il protocollo scelto non
129 sono supportati nel dominio.
130 \item[\errcode{ENFILE}] Il kernel non ha memoria sufficiente a creare una
131 nuova struttura per il socket.
132 \item[\errcode{EMFILE}] Si è ecceduta la tabella dei file.
133 \item[\errcode{EACCES}] Non si hanno privilegi per creare un socket nel
134 dominio o con il protocollo specificato.
135 \item[\errcode{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
136 \item[\errcode{ENOBUFS}] Non c'è sufficiente memoria per creare il socket
137 (può essere anche \errval{ENOMEM}).
139 inoltre, a seconda del protocollo usato, potranno essere generati altri
140 errori, che sono riportati nelle relative pagine di manuale.}
143 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
144 (definisce cioè, come vedremo in \secref{sec:sock_domain}, la famiglia di
145 protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
146 come vedremo in \secref{sec:sock_type}, lo stile di comunicazione) e
147 \param{protocol} il protocollo; in genere quest'ultimo è indicato
148 implicitamente dal tipo di socket, per cui di norma questo valore viene messo
149 a zero (con l'eccezione dei \textit{raw socket}).
151 Si noti che la creazione del socket si limita ad allocare le opportune
152 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
153 non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
154 attraverso i quali si vuole effettuare la comunicazione.
156 \subsection{Il dominio, o \textit{protocol family}}
157 \label{sec:sock_domain}
159 Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
160 tipi di socket, che vengono classificati raggruppandoli in quelli che si
161 chiamano \textsl{domini}. La scelta di un dominio equivale in sostanza alla
162 scelta di una famiglia di protocolli, e viene effettuata attraverso
163 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
164 suo nome simbolico che convenzionalmente inizia con una costante che inizia
165 per \texttt{PF\_}, iniziali di \textit{protocol family}, un altro nome con cui
166 si indicano i domini.
168 A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
169 associato ad una costante, che inizia invece per \texttt{AF\_} (da
170 \textit{address family}) che identifica il formato degli indirizzi usati in
171 quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
172 anche come \textit{name space},\footnote{nome che invece il manuale delle
173 \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
174 identificano il formato degli indirizzi usati in quel dominio per identificare
175 i capi della comunicazione.
180 \begin{tabular}[c]{|l|l|l|l|}
182 \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
185 \const{PF\_UNSPEC} & 0& Non specificato & \\
186 \const{PF\_LOCAL} & 1& Local communication & unix(7) \\
187 \const{PF\_UNIX}, \const{PF\_FILE}&1& & \\
188 \const{PF\_INET} & 2& IPv4 Internet protocols & ip(7) \\
189 \const{PF\_AX25} & 3& Amateur radio AX.25 protocol & \\
190 \const{PF\_IPX} & 4& IPX - Novell protocols & \\
191 \const{PF\_APPLETALK}& 5& Appletalk & ddp(7) \\
192 \const{PF\_NETROM} & 6& Amateur radio NetROM & \\
193 \const{PF\_BRIDGE} & 7& Multiprotocol bridge & \\
194 \const{PF\_ATMPVC} & 8& Access to raw ATM PVCs & \\
195 \const{PF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\
196 \const{PF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\
197 \const{PF\_ROSE} &11& Amateur Radio X.25 PLP & \\
198 \const{PF\_DECnet} &12& Reserved for DECnet project & \\
199 \const{PF\_NETBEUI} &13& Reserved for 802.2LLC project & \\
200 \const{PF\_SECURITY} &14& Security callback pseudo AF & \\
201 \const{PF\_KEY} &15& PF\_KEY key management API & \\
202 \const{PF\_NETLINK} &16& Kernel user interface device & netlink(7) \\
203 \const{PF\_PACKET} &17& Low level packet interface & packet(7) \\
204 \const{PF\_ASH} &18& Ash & \\
205 \const{PF\_ECONET} &19& Acorn Econet & \\
206 \const{PF\_ATMSVC} &20& ATM SVCs & \\
207 \const{PF\_SNA} &22& Linux SNA Project & \\
208 \const{PF\_IRDA} &23& IRDA sockets & \\
209 \const{PF\_PPPOX} &24& PPPoX sockets & \\
210 \const{PF\_WANPIPE} &25& Wanpipe API sockets & \\
211 \const{PF\_BLUETOOTH}&31& Bluetooth sockets & \\
214 \caption{Famiglie di protocolli definiti in Linux.}
215 \label{tab:net_pf_names}
218 L'idea alla base della distinzione fra questi due insiemi di costanti era che
219 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
220 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
221 il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
222 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
223 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
224 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
225 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
226 il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
227 e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
230 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
231 indirizzi, sono definiti dall'header \textit{socket.h}. Un elenco delle
232 famiglie di protocolli disponibili in Linux è riportato in
233 \tabref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
234 definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
235 compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
236 viene definita anche una costante \const{PF\_MAX} che indica il valore
237 massimo associabile ad un dominio (nel caso il suo valore 32).}
239 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
240 dall'utente generico, ad esempio in generale tutti i socket di tipo
241 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
242 di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
243 capability \texttt{CAP\_NET\_RAW}.
246 \subsection{Il tipo, o stile}
247 \label{sec:sock_type}
249 La scelta di un dominio non comporta però la scelta dello stile di
250 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
251 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
252 socket permette di scegliere lo stile di comunicazione indicando il tipo di
253 socket con l'argomento \param{type} di \func{socket}. Linux mette a
254 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
255 della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
258 \begin{basedescript}{\desclabelwidth{2.8cm}\desclabelstyle{\nextlinelabel}}
259 \item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati
260 bidirezionale, sequenziale e affidabile. Opera su una connessione con un
261 altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
262 byte (da cui il nome \textit{stream}).
263 \item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
264 (\textit{datagram}) di lunghezza massima fissata indirizzati singolarmente,
265 Non esiste una connessione e la trasmissione è effettuata in maniera non
267 \item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
268 bidirezionale, sequenziale e affidabile. Opera su una connessione con un
269 altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
270 massima fissata, ed devono essere letti integralmente da ciascuna
271 chiamata a \func{read}.
272 \item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
273 rete e alle varie interfacce. I normali programmi di comunicazione non
274 devono usarlo, è riservato all'uso di sistema.
275 \item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
276 affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
277 \item[\const{SOCK\_PACKET}] Obsoleto, non deve essere usato.
280 Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
281 e un tipo di socket sono valide, in quanto non è detto che in una famiglia
282 esista un protocollo per ciascuno dei diversi stili di comunicazione appena
288 \begin{tabular}{|l|c|c|c|c|c|}
290 \multicolumn{1}{|c|}{\textbf{Famiglia}}&
291 \multicolumn{5}{|c|}{\textbf{Tipo}}\\
294 &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}&
295 \const{SOCK\_PACKET}&\const{SOCK\_SEQPACKET} \\
297 \const{PF\_UNIX} & si & si & & & \\
299 \const{PF\_INET} & TCP & UDP & IPv4 & & \\
301 \const{PF\_INET6} & TCP & UDP & IPv6 & & \\
303 \const{PF\_IPX} & & & & & \\
305 \const{PF\_NETLINK} & & si & si & & \\
307 \const{PF\_X25} & & & & & si \\
309 \const{PF\_AX25} & & & & & \\
311 \const{PF\_ATMPVC} & & & & & \\
313 \const{PF\_APPLETALK} & & si & si & & \\
315 \const{PF\_PACKET} & & si & si & & \\
318 \caption{Combinazioni valide di dominio e tipo di protocollo per la
319 funzione \func{socket}.}
320 \label{tab:sock_sock_valid_combinations}
323 In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
324 valide possibili per le principali famiglie di protocolli. Per ogni
325 combinazione valida si è indicato il tipo di protocollo, o la parola
326 \textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
327 sono lasciate vuote le caselle per le combinazioni non supportate.
330 \section{Le strutture degli indirizzi dei socket}
331 \label{sec:sock_sockaddr}
333 Come si è visto nella creazione di un socket non si specifica nulla oltre al
334 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
335 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
336 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
339 Gli indirizzi infatti vengono specificati attraverso apposite strutture che
340 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
341 la comunicazione viene effettivamente realizzata. Ogni famiglia di protocolli
342 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
343 sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
344 iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
345 identificati dal suffisso finale, aggiunto al nome precedente.
348 \subsection{La struttura generica}
349 \label{sec:sock_sa_gen}
351 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
352 attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
353 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
354 nelle varie famiglie di protocolli; questo pone il problema di come passare
355 questi puntatori, il C moderno risolve questo problema coi i puntatori
356 generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
357 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
358 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
359 è riportata in \figref{fig:sock_sa_gen_struct}.
362 \footnotesize \centering
363 \begin{minipage}[c]{15cm}
364 \begin{lstlisting}[stepnumber=0]{}
366 sa_family_t sa_family; /* address family: AF_xxx */
367 char sa_data[14]; /* address (protocol-specific) */
371 \caption{La struttura generica degli indirizzi dei socket
373 \label{fig:sock_sa_gen_struct}
376 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
377 prototipo un puntatore a questa struttura; per questo motivo quando si
378 invocano dette funzioni passando l'indirizzo di un protocollo specifico
379 occorrerà eseguire una conversione del relativo puntatore.
381 I tipi di dati che compongono la struttura sono stabiliti dallo standard
382 POSIX.1g e li abbiamo riassunti in \tabref{tab:sock_data_types} con i
383 rispettivi file di include in cui sono definiti; la struttura è invece
384 definita nell'include file \file{sys/socket.h}.
389 \begin{tabular}{|l|l|l|}
391 \multicolumn{1}{|c|}{\textbf{Tipo}}&
392 \multicolumn{1}{|c|}{\textbf{Descrizione}}&
393 \multicolumn{1}{|c|}{\textbf{Header}} \\
396 \type{int8\_t} & intero a 8 bit con segno & \file{sys/types.h}\\
397 \type{uint8\_t} & intero a 8 bit senza segno & \file{sys/types.h}\\
398 \type{int16\_t} & intero a 16 bit con segno & \file{sys/types.h}\\
399 \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
400 \type{int32\_t} & intero a 32 bit con segno & \file{sys/types.h}\\
401 \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
403 \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
404 \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
405 un socket& \file{sys/socket.h}\\
407 \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
408 \file{netinet/in.h}\\
409 \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
410 \file{netinet/in.h}\\
413 \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
414 stabilito dallo standard POSIX.1g.}
415 \label{tab:sock_data_types}
418 In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
419 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
420 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
421 non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
422 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
424 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
425 di fare da riferimento per il casting, per il kernel le cose sono un po'
426 diverse, in quanto esso usa il puntatore per recuperare il campo
427 \var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
428 indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
429 sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
430 è stato mantenuto l'uso di questa struttura.
433 \subsection{La struttura degli indirizzi IPv4}
434 \label{sec:sock_sa_ipv4}
436 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
437 attraverso internet; la struttura per gli indirizzi per un socket internet (se
438 si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
439 \file{netinet/in.h} ed ha la forma mostrata in
440 \figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
443 \footnotesize\centering
444 \begin{minipage}[c]{15cm}
445 \begin{lstlisting}[stepnumber=0]{}
447 sa_family_t sin_family; /* address family: AF_INET */
448 in_port_t sin_port; /* port in network byte order */
449 struct in_addr sin_addr; /* internet address */
451 /* Internet address. */
453 in_addr_t s_addr; /* address in network byte order */
457 \caption{La struttura degli indirizzi dei socket internet (IPv4)
458 \structd{sockaddr\_in}.}
459 \label{fig:sock_sa_ipv4_struct}
462 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
463 internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
464 dettaglio il significato di questi numeri in \secref{sec:TCPel_port_num}). Il
465 protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
466 protocolli di livello superiore come TCP e UDP. Questa struttura però viene
467 usata anche per i socket RAW che accedono direttamente al livello di IP, nel
468 qual caso il numero della porta viene impostato al numero di protocollo.
470 Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
471 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
472 specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
473 chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
474 soltanto processi con i privilegi di amministratore (con user-ID effettivo
475 uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
476 usare la funzione \func{bind} (che vedremo in \secref{sec:TCPel_func_bind}) su
479 Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
480 come struttura (un resto di una implementazione precedente in cui questa era
481 una \direct{union} usata per accedere alle diverse classi di indirizzi) che
482 direttamente come intero. In \file{netinet/in.h} vengono definiti anche alcune
483 costanti per alcuni indirizzi speciali, che vedremo in
484 \tabref{tab:TCPel_ipv4_addr}.
486 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
487 essere specificati in quello che viene chiamato \textit{network order}, cioè
488 con i bit ordinati in formato \textit{big endian}, questo comporta la
489 necessità di usare apposite funzioni di conversione per mantenere la
490 portabilità del codice (vedi \secref{sec:sock_addr_func} per i dettagli del
491 problema e le relative soluzioni).
494 \subsection{La struttura degli indirizzi IPv6}
495 \label{sec:sock_sa_ipv6}
497 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
498 sostanzialmente identici ai precedenti; la parte in cui si trovano
499 praticamente tutte le differenze fra i due socket è quella della struttura
500 degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
501 in \figref{fig:sock_sa_ipv6_struct}.
504 \footnotesize \centering
505 \begin{minipage}[c]{15cm}
506 \begin{lstlisting}[stepnumber=0]{}
507 struct sockaddr_in6 {
508 uint16_t sin6_family; /* AF_INET6 */
509 in_port_t sin6_port; /* port number */
510 uint32_t sin6_flowinfo; /* IPv6 flow information */
511 struct in6_addr sin6_addr; /* IPv6 address */
512 uint32_t sin6_scope_id; /* Scope id (new in 2.4) */
515 uint8_t s6_addr[16]; /* IPv6 address */
519 \caption{La struttura degli indirizzi dei socket IPv6
520 \structd{sockaddr\_in6}.}
521 \label{fig:sock_sa_ipv6_struct}
524 Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
525 il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
526 il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
527 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
528 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
529 specifici dell'header dei pacchetti IPv6 (vedi \secref{sec:IP_ipv6head}) ed il
530 loro uso è sperimentale.
532 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, infine
533 il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il kernel
534 2.4, per gestire alcune operazioni riguardanti il multicasting.
536 Si noti che questa struttura ha una dimensione maggiore della struttura
537 \struct{sockaddr} generica vista in \figref{fig:sock_sa_gen_struct}, quindi
538 occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
539 di contenere i dati nelle dimensioni di quest'ultima.
542 \subsection{La struttura degli indirizzi locali}
543 \label{sec:sock_sa_local}
545 I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
546 comunicazione fra processi che stanno sulla stessa macchina (per questo
547 vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
548 hanno la caratteristica ulteriore di poter essere creati anche in maniera
549 anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
550 \secref{sec:ipc_socketpair}). Quando però si vuole fare riferimento esplicito
551 ad uno di questi socket si deve usare una struttura degli indirizzi di tipo
552 \struct{sockaddr\_un}, la cui definizione si è riportata in
553 \secref{fig:sock_sa_local_struct}.
556 \footnotesize \centering
557 \begin{minipage}[c]{15cm}
558 \begin{lstlisting}[stepnumber=0]{}
559 #define UNIX_PATH_MAX 108
561 sa_family_t sun_family; /* AF_UNIX */
562 char sun_path[UNIX_PATH_MAX]; /* pathname */
566 \caption{La struttura degli indirizzi dei socket locali (detti anche
567 \textit{unix domain}) \structd{sockaddr\_un} definita in \file{sys/un.h}.}
568 \label{fig:sock_sa_local_struct}
571 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
572 il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
573 può essere un file (di tipo socket) nel filesystem o una stringa univoca
574 (mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
575 specificato come una stringa (terminata da uno zero) corrispondente al
576 pathname del file; nel secondo invece \var{sun\_path} inizia con uno zero e
577 vengono usati come nome i restanti byte come stringa, senza terminazione.
580 \subsection{La struttura degli indirizzi AppleTalk}
581 \label{sec:sock_sa_appletalk}
583 I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
584 \file{netatalk} per implementare la comunicazione secondo il protocollo
585 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
586 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
587 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
588 opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
589 questo argomento principalmente per mostrare l'uso di un protocollo
592 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
593 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
594 \func{socket} deve essere nullo. È altresì possibile usare i socket raw
595 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
596 per \param{protocol} è \func{ATPROTO\_DDP}.
598 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
599 \struct{sockaddr\_atalk}, la cui definizione è riportata in
600 \figref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo il
601 file \file{netatalk/at.h}.
604 \footnotesize \centering
605 \begin{minipage}[c]{15cm}
606 \begin{lstlisting}[stepnumber=0]{}
607 struct sockaddr_atalk {
608 sa_family_t sat_family; /* address family */
609 uint8_t sat_port; /* port */
610 struct at_addr sat_addr; /* net/node */
618 \caption{La struttura degli indirizzi dei socket AppleTalk
619 \structd{sockaddr\_atalk}.}
620 \label{fig:sock_sa_atalk_struct}
623 Il campo \var{sat\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
624 campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
625 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
626 usati solo da processi con i privilegi di amministratore o con la capability
627 \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
628 struttura \var{sat\_addr}, e deve essere in \textit{network order} (vedi
629 \secref{sec:sock_endianess}); esso è composto da un parte di rete data dal
630 campo \var{s\_net}, che può assumere il valore \const{AT\_ANYNET}, che indica
631 una rete generica e vale anche per indicare la rete su cui si è, il singolo
632 nodo è indicato da \var{s\_node}, e può prendere il valore generico
633 \const{AT\_ANYNODE} che indica anche il nodo corrente, ed il valore
634 \const{ATADDR\_BCAST} che indica tutti i nodi della rete.
637 \subsection{La struttura degli indirizzi dei \textit{packet socket}}
638 \label{sec:sock_sa_packet}
640 I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
641 un'interfaccia specifica di Linux per inviare e ricevere pacchetti
642 direttamente su un'interfaccia di rete, senza passare per le routine di
643 gestione dei protocolli di livello superiore. In questo modo è possibile
644 implementare dei protocolli in user space, agendo direttamente sul livello
645 fisico. In genere comunque si preferisce usare la libreria \file{pcap}, che
646 assicura la portabilità su altre piattaforme, anche se con funzionalità
649 Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
650 Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
651 collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
652 del dispositivo e viceversa. In questo modo, in fase di trasmissione, il
653 contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
654 fornito dall'utente. In fase di ricezione invece tutto il contenuto del
655 pacchetto viene passato inalterato sul socket, anche se il kernel analizza
656 comunque il pacchetto, riempiendo gli opportuni campi della struttura
657 \struct{sockaddr\_ll} ad esso associata.
659 Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
660 livello di rete. In questo caso in fase di ricezione l'intestazione del
661 protocollo di collegamento viene rimossa prima di passare il resto del
662 pacchetto all'utente, mentre in fase di trasmissione viene creata una
663 opportuna intestazione per il protocollo a livello di collegamento
664 utilizzato, usando le informazioni necessarie che devono essere specificate
665 sempre con una struttura \struct{sockaddr\_ll}.
667 Nella creazione di un \textit{packet socket} il valore dell'argomento
668 \param{protocol} di \func{socket} serve a specificare, in \textit{network
669 order}, il numero identificativo del protocollo di collegamento si vuole
670 utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
671 quelli disponibili in Linux sono accessibili attraverso opportune costanti
672 simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
673 speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
674 pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
675 di questi socket è una operazione privilegiata e può essere effettuati solo da
676 un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
677 la capability \const{CAP\_NET\_RAW}.
679 Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
680 specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
681 provengono; se si vuole limitare il passaggio ad una interfaccia specifica
682 occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
685 \footnotesize \centering
686 \begin{minipage}[c]{15cm}
687 \begin{lstlisting}[stepnumber=0]{}
689 unsigned short sll_family; /* Always AF_PACKET */
690 unsigned short sll_protocol; /* Physical layer protocol */
691 int sll_ifindex; /* Interface number */
692 unsigned short sll_hatype; /* Header type */
693 unsigned char sll_pkttype; /* Packet type */
694 unsigned char sll_halen; /* Length of address */
695 unsigned char sll_addr[8]; /* Physical layer address */
699 \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
700 \textit{packet socket}.}
701 \label{fig:sock_sa_packet_struct}
704 Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
705 \struct{sockaddr\_ll}, e la sua definizione è riportata in
706 \figref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
707 leggermente diverso rispetto a quanto visto finora per gli altri tipi di
708 socket. Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
709 scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
710 specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
711 tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
712 al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
713 entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
716 Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
717 \const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
718 e deve essere indicato in \textit{network order}, facendo uso delle costanti
719 simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
720 l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
721 stesso tipo (se ad esempio si hanno più schede ethernet), permette di
722 selezionare quella con cui si vuole operare (un valore nullo indica qualunque
723 interfaccia). Questi sono i due soli campi che devono essere specificati
724 quando si vuole selezionare una interfaccia specifica, usando questa struttura
725 con la funzione \func{bind}.
727 I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
728 l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
729 relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
730 collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il
731 MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
732 ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
733 pacchetti, in questo caso tutti gli altri campi devono essere nulli.
735 Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
736 \file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
737 pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
738 senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
739 seguenti valori: \var{PACKET\_HOST} per un pacchetto indirizzato alla macchina
740 ricevente, \var{PACKET\_BROADCAST} per un pacchetto di broadcast,
741 \var{PACKET\_MULTICAST} per un pacchetto inviato ad un indirizzo fisico di
742 multicast, \var{PACKET\_OTHERHOST} per un pacchetto inviato ad un'altra
743 stazione (e ricevuto su un'interfaccia in modo promiscuo),
744 \var{PACKET\_OUTGOING} per un pacchetto originato dalla propria macchina che
745 torna indietro sul socket.
747 Si tenga presente infine che in fase di ricezione, anche se si richiede il
748 troncamento del pacchetto, le funzioni \func{recvmsg}, \func{recv} e
749 \func{recvfrom} restituiranno comunque la lunghezza effettiva del pacchetto
750 così come arrivato sulla linea.
753 %% \subsection{La struttura degli indirizzi DECnet}
754 %% \label{sec:sock_sa_decnet}
756 %% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
757 %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
758 %% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
759 %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
764 % \subsection{Il passaggio delle strutture}
765 % \label{sec:sock_addr_pass}
767 % Come detto nelle funzioni della API dei socket le strutture degli indirizzi
768 % vengono sempre passate per riferimento usando un puntatore; anche la lunghezza
769 % della struttura è passata come argomento, ma in questo caso la modalità del
770 % passaggio dipende dalla direzione del medesimo, dal processo al kernel o
773 % In particolare le tre funzioni \texttt{bind}, \texttt{connect} e
774 % \texttt{sendto} passano la struttura al kernel, in questo caso è passata
775 % \textsl{per valore} anche la dimensione della medesima
778 % Le funzioni \texttt{accept}, \texttt{recvfrom}, \texttt{getsockname} e
779 % \texttt{getpeername} invece ricevono i valori del kernel
783 \section{Le funzioni di conversione degli indirizzi}
784 \label{sec:sock_addr_func}
786 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
787 indirizzi, limitandoci però agli indirizzi internet.
789 Come accennato gli indirizzi e i numeri di porta usati nella rete devono
790 essere forniti in formato opportuno (il \textit{network order}). Per capire
791 cosa significa tutto ciò occorre introdurre un concetto generale che tornerà
792 utile anche in seguito.
795 \subsection{La \textit{endianess}\index{endianess}}
796 \label{sec:sock_endianess}
798 La rappresentazione di un numero binario in un computer può essere fatta in
799 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
800 endian} a seconda di come i singoli bit vengono aggregati per formare le
801 variabili intere (ed in genere in diretta corrispondenza a come sono poi in
802 realtà cablati sui bus interni del computer).
804 Per capire meglio il problema si consideri un intero a 16 bit scritto in una
805 locazione di memoria posta ad un certo indirizzo. I singoli bit possono essere
806 disposti un memoria in due modi: a partire dal più significativo o a partire
807 dal meno significativo. Così nel primo caso si troverà il byte che contiene i
808 bit più significativi all'indirizzo menzionato e il byte con i bit meno
809 significativi nell'indirizzo successivo; questo ordinamento è detto
810 \textit{little endian} dato che il dato finale è la parte ``piccola'' del
811 numero. Il caso opposto, in cui si parte dal bit meno significativo è detto
812 per lo stesso motivo \textit{big endian}.
814 La \textit{endianess}\index{endianess} di un computer dipende essenzialmente
815 dalla architettura hardware usata; Intel e Digital usano il \textit{little
816 endian}, Motorola, IBM, Sun (sostanzialmente tutti gli altri) usano il
817 \textit{big endian}. Il formato della rete è anch'esso \textit{big endian},
818 altri esempi di uso di questi formati sono quello del bus PCI, che è
819 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
821 Esistono poi anche dei processori che possono scegliere il tipo di formato
822 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
823 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
824 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
825 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
828 \subsection{Le funzioni per il riordinamento}
829 \label{sec:sock_func_ord}
831 Il problema connesso all'endianess\index{endianess} è che quando si passano
832 dei dati da un tipo di architettura all'altra i dati vengono interpretati in
833 maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
834 con i due byte in cui è suddiviso scambiati di posto, e ne sarà quindi
835 invertito l'ordine di lettura per cui, per riavere il valore originale,
836 dovranno essere rovesciati.
838 Per questo motivo si usano delle funzioni di conversione che servono a tener
839 conto automaticamente della possibile differenza fra l'ordinamento usato sul
840 computer e quello che viene usato nelle trasmissione sulla rete; queste
841 funzioni sono \funcd{htonl}, \funcd{htons}, \funcd{ntonl} e \funcd{ntons} ed i
842 rispettivi prototipi sono:
844 \headdecl{netinet/in.h}
845 \funcdecl{unsigned long int htonl(unsigned long int hostlong)}
846 Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
849 \funcdecl{unsigned short int htons(unsigned short int hostshort)}
850 Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
853 \funcdecl{unsigned long int ntonl(unsigned long int netlong)}
854 Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
857 \funcdecl{unsigned sort int ntons(unsigned short int netshort)}
858 Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
861 \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non
865 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
866 l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
867 \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
868 \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
869 indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
872 Usando queste funzioni si ha la conversione automatica: nel caso in cui la
873 macchina che si sta usando abbia una architettura \textit{big endian} queste
874 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
875 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
876 assicurare la portabilità del codice su tutte le architetture.
879 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
881 \label{sec:sock_func_ipv4}
883 Un secondo insieme di funzioni di manipolazione serve per passare dal formato
884 binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
885 dei numeri IP che si usa normalmente.
887 Le prime tre funzioni di manipolazione riguardano la conversione degli
888 indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
889 cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
890 \texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
891 order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
892 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
893 \funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
895 \headdecl{arpa/inet.h}
897 \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
898 dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
900 \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
901 la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
903 \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
904 Converte un indirizzo IP in una stringa \textit{dotted decimal}.
906 \bodydesc{Tutte queste le funzioni non generano codice di errore.}
909 La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
910 network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
911 nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
912 un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
913 tipicamente sono trentadue bit a uno. Questo però comporta che la stringa
914 \texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
915 con questa funzione; per questo motivo essa è generalmente deprecata in favore
916 di \func{inet\_aton}.
918 La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
919 nell'indirizzo binario che viene memorizzato nell'opportuna struttura
920 \struct{in\_addr} (si veda \secref{fig:sock_sa_ipv4_struct}) situata
921 all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
922 modo da poterla usare direttamente con il puntatore usato per passare la
923 struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
924 in caso di fallimento. Se usata con \param{dest} inizializzato a \val{NULL}
925 effettua la validazione dell'indirizzo.
927 L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
928 dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
929 alla stringa che contiene l'espressione in formato dotted decimal. Si deve
930 tenere presente che la stringa risiede in memoria statica, per cui questa
931 funzione non è rientrante.
934 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
935 \label{sec:sock_conv_func_gen}
937 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
938 motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
939 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
940 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
941 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
944 % \begin{figure}[htb]
947 % \caption{Schema della rappresentazioni utilizzate dalle funzioni di
948 % conversione \texttt{inet\_pton} e \texttt{inet\_ntop} }
949 % \label{fig:sock_inet_conv_func}
953 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
954 indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
955 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
956 indirizzo; il suo prototipo è:
957 \begin{prototype}{sys/socket.h}
958 {int inet\_pton(int af, const char *src, void *addr\_ptr)}
960 Converte l'indirizzo espresso tramite una stringa nel valore numerico.
962 \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
963 una famiglia di indirizzi non valida, con \var{errno} che assume il valore
964 \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
965 indirizzo valido, ed un valore positivo in caso di successo.}
968 La funzione converte la stringa indicata tramite \param{src} nel valore
969 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
970 memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
971 restituisce un valore positivo in caso di successo, nullo se la stringa non
972 rappresenta un indirizzo valido, e negativo se \param{af} specifica una
973 famiglia di indirizzi non valida.
975 La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
976 indirizzo in una stringa; il suo prototipo è:
977 \begin{prototype}{sys/socket.h}
978 {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
979 Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
981 \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
982 convertita in caso di successo e \val{NULL} in caso di fallimento, nel
983 qual caso \var{errno} assume i valori:
985 \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
986 dell'indirizzo eccedono la lunghezza specificata da \param{len}.
987 \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
992 La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
993 in una stringa che viene copiata nel buffer puntato dall'indirizzo
994 \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
995 essere almeno \const{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
996 \const{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
997 comunque venire specificata attraverso il parametro \param{len}.
999 Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
1000 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
1001 per IPv6), che devono essere precedentemente allocate e passate attraverso il
1002 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
1003 può essere nullo e deve essere allocato precedentemente.
1005 Il formato usato per gli indirizzi in formato di presentazione è la notazione
1006 \textit{dotted decimal} per IPv4 e quello descritto in
1007 \secref{sec:IP_ipv6_notation} per IPv6.
1012 \section{Un esempio di applicazione}
1013 \label{sec:sock_appplication}
1015 Per evitare di rendere questa introduzione ai socket puramente teorica
1016 iniziamo con il mostrare un esempio di un client TCP elementare. Prima di
1017 passare agli esempi del client e del server, ritorniamo con maggiori dettagli
1018 su una caratteristica delle funzioni di I/O, già accennata in
1019 \secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
1020 particolarmente rilevante, e che ci tornerà utile anche in seguito.
1023 \subsection{Il comportamento delle funzioni di I/O}
1024 \label{sec:sock_io_behav}
1026 Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
1027 le funzioni di input/output non sempre hanno lo stesso comportamento che
1028 avrebbero con i normali file di dati (in particolare questo accade per i
1029 socket di tipo stream).
1031 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
1032 possano restituire in input o scrivere in output un numero di byte minore di
1033 quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
1034 comportamento normale per l'I/O su file, ma con i normali file di dati il
1035 problema si avverte solo quando si incontra la fine del file, in generale non
1036 è così, e con i socket questo è particolarmente evidente.
1038 Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
1039 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
1040 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
1041 sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
1042 \const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
1043 \secref{sec:ipc_pipes}).
1048 \begin{lstlisting}{}
1051 ssize_t FullRead(int fd, void *buf, size_t count)
1057 while (nleft > 0) { /* repeat until no left */
1058 if ( (nread = read(fd, buf, nleft)) < 0) {
1059 if (errno == EINTR) { /* if interrupted by system call */
1060 continue; /* repeat the loop */
1062 return(nread); /* otherwise exit */
1064 } else if (nread == 0) { /* EOF */
1065 break; /* break loop here */
1067 nleft -= nread; /* set left to read */
1068 buf +=nread; /* set pointer */
1070 return (count - nleft);
1073 \caption{Funzione \func{FullRead}, legge esattamente \var{count} byte da un
1074 file descriptor, iterando opportunamente le letture.}
1075 \label{fig:sock_FullRead_code}
1078 Per questo motivo, seguendo l'esempio di W. R. Stevens in \cite{UNP1}, si sono
1079 definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
1080 lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
1081 ritornare dopo avere letto o scritto esattamente il numero di byte
1082 specificato; il sorgente è riportato rispettivamente in
1083 \figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
1084 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
1090 \begin{lstlisting}{}
1093 ssize_t FullWrite(int fd, const void *buf, size_t count)
1099 while (nleft > 0) { /* repeat until no left */
1100 if ( (nwritten = write(fd, buf, nleft)) < 0) {
1101 if (errno == EINTR) { /* if interrupted by system call */
1102 continue; /* repeat the loop */
1104 return(nwritten); /* otherwise exit with error */
1107 nleft -= nwritten; /* set left to write */
1108 buf +=nwritten; /* set pointer */
1113 \caption{Funzione \func{FullWrite}, scrive \var{count} byte su un socket.}
1114 \label{fig:sock_FullWrite_code}
1117 Come si può notare le funzioni ripetono la lettura/scrittura in un ciclo fino
1118 all'esaurimento del numero di byte richiesti, in caso di errore viene
1119 controllato se questo è \errcode{EINTR} (cioè un'interruzione della system call
1120 dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
1121 l'errore viene ritornato interrompendo il ciclo.
1123 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
1124 arrivati alla fine del file (per i socket questo significa in genere che
1125 l'altro capo è stato chiuso, e non è quindi più possibile leggere niente) e
1126 pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
1130 \subsection{Un primo esempio di client}
1131 \label{sec:net_cli_sample}
1133 Lo scopo di questo esempio è fornire un primo approccio alla programmazione di
1134 rete e vedere come si usano le funzioni descritte in precedenza, alcune delle
1135 funzioni usate nell'esempio saranno trattate in dettaglio nel capitolo
1136 successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
1137 definizioni precise e dettagli di funzionamento che saranno trattati
1138 estensivamente più avanti.
1140 In \figref{fig:net_cli_code} è riportata la sezione principale del codice del
1141 nostro client elementare per il servizio \textit{daytime}, un servizio
1142 standard che restituisce l'ora locale della macchina a cui si effettua la
1145 \begin{figure}[!htb]
1147 \begin{lstlisting}{}
1148 #include <sys/types.h> /* predefined types */
1149 #include <unistd.h> /* include unix standard library */
1150 #include <arpa/inet.h> /* IP addresses conversion utilities */
1151 #include <sys/socket.h> /* socket library */
1152 #include <stdio.h> /* include standard I/O library */
1154 int main(int argc, char *argv[])
1158 struct sockaddr_in serv_add;
1159 char buffer[MAXLINE];
1162 if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
1163 perror("Socket creation error");
1166 /* initialize address */
1167 memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
1168 serv_add.sin_family = AF_INET; /* address type is INET */
1169 serv_add.sin_port = htons(13); /* daytime post is 13 */
1170 /* build address using inet_pton */
1171 if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
1172 perror("Address creation error");
1175 /* extablish connection */
1176 if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
1177 perror("Connection error");
1180 /* read daytime from server */
1181 while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
1183 if (fputs(buffer, stdout) == EOF) { /* write daytime */
1184 perror("fputs error");
1190 perror("Read error");
1197 \caption{Esempio di codice di un client elementare per il servizio daytime.}
1198 \label{fig:net_cli_code}
1201 Il sorgente completo del programma (\file{ElemDaytimeTCPClient.c}, che
1202 comprende il trattamento delle opzioni e una funzione per stampare un
1203 messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
1204 può essere compilato su una qualunque macchina Linux.
1206 Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
1207 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
1208 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
1209 comando (effettuata con le apposite routine illustrate in
1210 \capref{sec:proc_opt_handling}).
1212 Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
1213 (\const{AF\_INET}), di tipo TCP \const{SOCK\_STREAM}. La funzione
1214 \func{socket} ritorna il descrittore che viene usato per identificare il
1215 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
1216 stampa un errore con la relativa routine e si esce.
1218 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
1219 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
1220 il numero della porta del servizio. Il primo passo è inizializzare tutto a
1221 zero, per poi inserire il tipo di protocollo e la porta (usando per
1222 quest'ultima la funzione \func{htons} per convertire il formato dell'intero
1223 usato dal computer a quello usato nella rete), infine si utilizza la funzione
1224 \func{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di
1227 Usando la funzione \func{connect} sul socket creato in precedenza
1228 (\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
1229 server specificato dall'indirizzo immesso nella struttura passata come secondo
1230 argomento, il terzo argomento è la dimensione di detta struttura. Dato che
1231 esistono diversi tipi di socket, si è dovuto effettuare un cast della
1232 struttura inizializzata in precedenza, che è specifica per i socket IPv4. Un
1233 valore di ritorno negativo implica il fallimento della connessione.
1235 Completata con successo la connessione il passo successivo (\texttt{\small
1236 34--40}) è leggere la data dal socket; il server invierà sempre una stringa
1237 di 26 caratteri della forma \verb|Wed Apr 4 00:53:00 2001\r\n|, che viene
1238 letta dalla funzione \func{read} e scritta su \file{stdout}.
1240 Dato il funzionamento di TCP la risposta potrà tornare in un unico pacchetto
1241 di 26 byte (come avverrà senz'altro nel caso in questione) ma potrebbe anche
1242 arrivare in 26 pacchetti di un byte. Per questo nel caso generale non si può
1243 mai assumere che tutti i dati arrivino con una singola lettura, pertanto
1244 quest'ultima deve essere effettuata in un ciclo in cui si continui a leggere
1245 fintanto che la funzione \func{read} non ritorni uno zero (che significa che
1246 l'altro capo ha chiuso la connessione) o un numero minore di zero (che
1247 significa un errore nella connessione).
1249 Si noti come in questo caso la fine dei dati sia specificata dal server che
1250 chiude la connessione; questa è una delle tecniche possibili (è quella usata
1251 pure dal protocollo HTTP), ma ce ne possono essere altre, ad esempio FTP marca
1252 la conclusione di un blocco di dati con la sequenza ASCII \verb|\r\n|
1253 (carriage return e line feed), mentre il DNS mette la lunghezza in testa ad
1254 ogni blocco che trasmette. Il punto essenziale è che TCP non provvede nessuna
1255 indicazione che permetta di marcare dei blocchi di dati, per cui se questo è
1256 necessario deve provvedere il programma stesso.
1258 \subsection{Un primo esempio di server}
1259 \label{sec:net_serv_sample}
1261 Dopo aver illustrato il client daremo anche un esempio di un server
1262 elementare, in grado di rispondere al precedente client. Il listato è
1263 nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo
1264 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
1265 directory \file{sources}.
1267 \begin{figure}[!htbp]
1269 \begin{lstlisting}{}
1270 #include <sys/types.h> /* predefined types */
1271 #include <unistd.h> /* include unix standard library */
1272 #include <arpa/inet.h> /* IP addresses conversion utilities */
1273 #include <sys/socket.h> /* socket library */
1274 #include <stdio.h> /* include standard I/O library */
1278 int main(int argc, char *argv[])
1281 * Variables definition
1283 int list_fd, conn_fd;
1285 struct sockaddr_in serv_add;
1286 char buffer[MAXLINE];
1290 if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
1291 perror("Socket creation error");
1294 /* initialize address */
1295 memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
1296 serv_add.sin_family = AF_INET; /* address type is INET */
1297 serv_add.sin_port = htons(13); /* daytime port is 13 */
1298 serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
1300 if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
1301 perror("bind error");
1304 /* listen on socket */
1305 if (listen(list_fd, BACKLOG) < 0 ) {
1306 perror("listen error");
1309 /* write daytime to client */
1311 if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
1312 perror("accept error");
1315 timeval = time(NULL);
1316 snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
1317 if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
1318 perror("write error");
1327 \caption{Esempio di codice di un semplice server per il servizio daytime.}
1328 \label{fig:net_serv_code}
1331 Come per il client si includono gli header necessari a cui è aggiunto quello
1332 per trattare i tempi, e si definiscono alcune costanti e le variabili
1333 necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
1334 sono omesse le parti relative al trattamento delle opzioni da riga di comando.
1336 La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
1337 come pure l'inizializzazione della struttura \struct{sockaddr\_in}, anche in
1338 questo caso si usa la porta standard del servizio daytime, ma come indirizzo
1339 IP si il valore predefinito \const{INET\_ANY} che corrisponde ad un indirizzo
1340 generico (\texttt{\small 27--31}).
1342 Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
1343 \func{bind} che permette di associare la precedente struttura al socket, in
1344 modo che quest'ultimo possa essere usato per accettare connessioni su una
1345 qualunque delle interfacce di rete locali.
1347 Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
1348 socket, questo viene effettuato con la funzione \func{listen} che dice al
1349 kernel di accettare connessioni per il socket specificato, la funzione indica
1350 inoltre, con il secondo parametro, il numero massimo di connessioni che il
1351 kernel accetterà di mettere in coda per il suddetto socket.
1353 Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
1354 viene chiamato anche \textit{listening descriptor}) a questo punto il processo
1355 è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
1356 funzione \func{accept}, fin quando non arriva e viene accettata una
1357 connessione da un client.
1359 Quando questo avviene \func{accept} ritorna un secondo descrittore di socket,
1360 che viene chiamato \textit{connected descriptor} che è quello che viene usato
1361 dalla successiva chiamata alla \func{write} per scrivere la risposta al
1362 client, una volta che si è opportunamente (\texttt{\small 48--49}) costruita
1363 la stringa con la data da trasmettere. Completata la trasmissione il nuovo
1364 socket viene chiuso (\texttt{\small 54}). Il tutto è inserito in un ciclo
1365 infinito (\texttt{\small 42--55}) in modo da poter ripetere l'invio della data
1366 ad una successiva connessione.
1368 È importante notare che questo server è estremamente elementare, infatti a
1369 parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
1370 un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
1371 scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
1372 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
1373 attiva e il terminale da cui lo si è lanciato è stato sconnesso),
1374 occorrerebbero delle opportune modifiche.
1378 %%% Local Variables:
1380 %%% TeX-master: "gapil"