\chapter{Socket TCP elementari}
\label{cha:elem_TCP_sock}
-In questo capitolo iniziamo ad approndire la conoscenza dei socket TCP,
+In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate
nei due esempi elementari forniti in precedenza (vedi
\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}), previa una
di una connessione, che possono essere osservati per ciascun socket attivo con
l'uso del programma \texttt{netstat}.
-\subsection{La creazione della connessione: il \textit{three way handushake}}
+\subsection{La creazione della connessione: il \textit{three way handshake}}
\label{sec:TCPel_conn_cre}
Il processo che porta a creare una connessione TCP è chiamato \textit{three
- way handushake}; la successione tipica degli eventi (la stessa che si
+ way handshake}; la successione tipica degli eventi (la stessa che si
verifica utilizzando il codice dei due precedenti esempi elementari
\figref{fig:net_cli_code} e \figref{fig:net_serv_code}) che porta alla
creazione di una connessione è la seguente:
che implementa il protocollo) per realizzare la comunicazione, fra questi
dati ci sono una serie di flag usati per gestire la connessione, come
\texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
- come \texttt{SYN} (che sta per \textit{sincronize}) corrispondono a
+ come \texttt{SYN} (che sta per \textit{syncronize}) corrispondono a
funzioni particolari del protocollo e danno il nome al segmento, (per
maggiori dettagli vedere \capref{cha:tcp_protocol})}, in sostanza viene
inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
\item \textit{MSS option} Sta per \textit{maximum segment size}, con questa
opzione ciascun capo della connessione annuncia all'altro il massimo
ammontare di dati che vorrebbe accettare per ciascun segmento nella
- connesione corrente. È possibile leggere e scrivere questo valore attraverso
+ connessione corrente. È possibile leggere e scrivere questo valore attraverso
l'opzione del socket \texttt{TCP\_MAXSEG}.
\item \textit{window scale option} come spiegato in \capref{cha:tcp_protocol} il
protocollo TCP implementa il controllo di flusso attraverso una
\textsl{finestra annunciata} (\textit{advertized window}) con la quale
ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
- memoria per i dati. Questo è un numero a 16 bit dell'haeader, che così può
- indicare un massimo di 65535 bytes (anche se linux usa come massimo 32767
+ memoria per i dati. Questo è un numero a 16 bit dell'header, che così può
+ indicare un massimo di 65535 bytes (anche se Linux usa come massimo 32767
per evitare problemi con alcuni stack bacati che usano l'aritmetica con
segno per implementare lo stack TCP); ma alcuni tipi di connessione come
quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi
protocollo, le ultime due opzioni (trattate nell'RFC 1323) sono meno comuni;
vengono anche dette \textit{long fat pipe options} dato che questo è il nome
che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
-elevati. In ogni caso linux supporta pienamente entrambe le opzioni.
+elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
\subsection{La terminazione della connessione}
\label{sec:TCPel_conn_term}
Mentre per creare una connessione occorre un interscambio di tre segmenti, la
-procedura di chiusura ne richede quattro; ancora una volta si può fare
+procedura di chiusura ne richiede quattro; ancora una volta si può fare
riferimento al codice degli esempi \figref{fig:net_cli_code} e
\figref{fig:net_serv_code}, in questo caso la successione degli eventi è la
seguente:
\item L'altro capo della connessione riceve il FIN ed esegue la
\textit{chiusura passiva} (da \textit{passive close}); al FIN, come per
tutti i pacchetti, viene risposto con un ACK. Inoltre il ricevimento del FIN
- viene passato al processo che ha aperto il socket come un end of file sulla
+ viene passato al processo che ha aperto il socket come un end-of-file sulla
lettura (dopo che ogni altro eventuale dato rimasto in coda è stato
ricevuto), dato che il ricevimento di un FIN significa che non si
riceveranno altri dati sulla connessione.
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro; normalmente giacché in alcune
-sitazioni il FIN del passo 1) è inviato insieme a dei dati. Comunque non è
+situazioni il FIN del passo 1) è inviato insieme a dei dati. Comunque non è
detto, anche se è possibile, che i segmenti inviati nei passi 2 e 3, siano
accorpati in un singolo segmento. In \nfig\ si è rappresentato graficamente lo
sequenza di scambio dei segmenti che stabilisce la connessione.
viene terminato da un segnale tutte le connessioni aperte verranno chiuse.
Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo
-piu avanti in \secref{sec:TCPsimp_echo_example}) sia il client ad eseguire la
+più avanti in \secref{sec:TCPsimp_echo_example}) sia il client ad eseguire la
chiusura attiva, nella realtà questa può essere eseguita da uno qualunque dei
due capi della comunicazione (come in fatto in precedenza da
\figref{fig:net_serv_code}), e benché quello del client sia il caso più comune
\end{figure}
La connessione viene iniziata dal client che annuncia un MSS di 1460 (un
-valore tipico per IPv4 su ethernet) con linux, il server risponde con lo
+valore tipico per IPv4 su ethernet) con Linux, il server risponde con lo
stesso valore (ma potrebbe essere anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
più di MSL secondi.
Ogni implementazione del TCP deve scegliere un valore per la MSL (l'RFC1122
-raccomanda 2 minuti, linux usa 30 secondi), questo comporta una durata dello
+raccomanda 2 minuti, Linux usa 30 secondi), questo comporta una durata dello
stato \texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra
1 a 4 minuti.
non ricevendo risposta, provvederà alla ritrasmissione e se nel frattempo sarà
stata stabilita una strada alternativa il pacchetto ritrasmesso giungerà a
destinazione. Ma se dopo un po' di tempo (che non supera il limite dell'MSL)
-l'anomalia viene a cessare il circolo di instadamento viene spezzato i
+l'anomalia viene a cessare il circolo di instradamento viene spezzato i
pacchetti intrappolati potranno essere inviati alla destinazione finale, con
la conseguenza di avere dei pacchetti duplicati; questo è un caso che il TCP
deve essere in grado di gestire.
In realtà rispetto a quanto indicato nell'RFC1700 i vari sistemi hanno fatto
scelte diverse per le porte effimere, in particolare in \nfig\ sono riportate
-quelle di BSD, Solaris e linux. Nel caso di linux poi la scelta fra i due
-intervali possibili viene fatta dinamicamente a seconda della memoria a
-disposizione del kernel per gestire le rative tabelle.
+quelle di BSD, Solaris e Linux. Nel caso di Linux poi la scelta fra i due
+intervalli possibili viene fatta dinamicamente a seconda della memoria a
+disposizione del kernel per gestire le relative tabelle.
\begin{figure}[!htb]
\centering
Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
che fare con un'applicazione client/server (come quella che scriveremo in
-\secref{sec:TCPel_cunc_serv}) esaminaremo cosa accade con le connessioni nel
+\secref{sec:TCPel_cunc_serv}) esamineremo cosa accade con le connessioni nel
caso di un server TCP che deve gestire connessioni multiple.
-Se esguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere
+Se eseguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere
indirizzo 195.110.112.152) potremo avere un risultato del tipo:
\begin{verbatim}
Active Internet connections (servers and established)
Questo ci mostra ad esempio che il server ssh ha compiuto un'apertura passiva
mettendosi in ascolto sulla porta 22 riservata a questo servizio e che si è
posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
-associati alle interfaccie locali; la notazione 0.0.0.0 usata da netstat è
+associati alle interfacce locali; la notazione 0.0.0.0 usata da netstat è
equivalente all'asterisco utilizzato per il numero di porta ed indica il
valore generico, e corrisponde al valore \texttt{INADDR\_ANY} definito in
\texttt{arpa/inet.h}.
Una volta che ci si vorrà collegare a questa macchina da un'altra posta
all'indirizzo 192.84.146.100 si potrà lanciare un client \texttt{ssh} per
-creare una connessione verso la precedente, e il kernel associerà al suddetto
+creare una connessione verso la precedente, e il kernel assocerà al suddetto
una porta effimera che per esempio potrà essere la 21100, la connessione
allora sarà espressa dalla socket pair $(192.84.146.100:21100,
195.110.112.152.22)$.
sul socket originale.
Se a questo punto lanciamo un'altra volta il client ssh per una seconda
-conessione quello che otterremo usando netstat sarà qualcosa del genere:
+connessione quello che otterremo usando netstat sarà qualcosa del genere:
\begin{verbatim}
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
alle connessioni che arrivano verso tale indirizzo.
Normalmente un client non specifica mai un indirizzo ad un suo socket, ed il
-kernel sceglie l'indirizzo di orgine quando viene effettuata la connessione
+kernel sceglie l'indirizzo di origine quando viene effettuata la connessione
sulla base dell'interfaccia usata per trasmettere i pacchetti, (che dipende
dalle regole di instradamento usate per raggiungere il server).
Se un server non specifica il suo indirizzo locale il kernel userà come
Per specificare un indirizzo generico con IPv4 si usa il valore
\texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
-è pari a zero, nell'esempio \figref{fig:net_serv_sample} si è usata
+è pari a zero, nell'esempio \figref{fig:net_serv_code} si è usata
un'assegnazione immediata del tipo:
\begin{verbatim}
serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
Si noti che si è usato \texttt{htonl} per assegnare il valore
\texttt{INADDR\_ANY}; benché essendo questo pari a zero il riordinamento sia
-inutile; ma dato che tutte le constanti \texttt{INADDR\_} sono definite
+inutile; ma dato che tutte le costanti \texttt{INADDR\_} sono definite
secondo l'ordinamento della macchina è buona norma usare sempre la funzione
\texttt{htonl}.
\item \texttt{EAFNOSUPPORT} l'indirizzo non ha una famiglia di indirizzi
corretta nel relativo campo.
\item \texttt{EACCESS, EPERM} si è tentato di eseguire una connessione ad un
- indirizzo broacast senza che il socket fosse stato abilitato per il
+ indirizzo broadcast senza che il socket fosse stato abilitato per il
broadcast.
\end{errlist}
\end{prototype}
dopo circa 180 secondi.
%
% Le informazioni su tutte le opzioni settabili via /proc stanno in
-% linux/Documentation/networking/ip-sysctl.txt
+% Linux/Documentation/networking/ip-sysctl.txt
%
\item Il client riceve come risposta al SYN un RST significa che non c'è
nessun programma in ascolto per la connessione sulla porta specificata (il
- che vuol dire probablmente che o si è sbagliato il numero della porta o che
+ che vuol dire probabilmente che o si è sbagliato il numero della porta o che
non è stato avviato il server), questo è un errore fatale e la funzione
ritorna non appena il RST viene ricevuto riportando un errore
\texttt{ECONNREFUSED}.
Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
quando arriva un SYN per una porta che non ha nessun server in ascolto,
- quando il TCP abortisce una connessione in corso, quandi TCP riceve un
+ quando il TCP abortisce una connessione in corso, quando TCP riceve un
segmento per una connessione che non esiste.
\item Il SYN del client provoca l'emissione di un messaggio ICMP di
destinazione non raggiungibile. In questo caso dato che il messaggio può
- essere dovuto ad una condizione transitoria si ripete l'emmissione dei SYN
+ essere dovuto ad una condizione transitoria si ripete l'emissione dei SYN
come nel caso precedente, fino al timeout, e solo allora si restituisce il
codice di errore dovuto al messaggio ICMP, che da luogo ad un
\texttt{ENETUNREACH}.
Si noti infine che con la funzione \texttt{connect} si è specificato solo
indirizzo e porta del server, quindi solo una metà della socket pair; essendo
-questa funzione usata nei client l'altra metà contentente indirizzo e porta
+questa funzione usata nei client l'altra metà contenente indirizzo e porta
locale viene lasciata all'assegnazione automatica del kernel, e non è
necessario effettuare una \texttt{bind}.
\begin{enumerate}
\item Una coda delle connessioni incomplete (\textit{incomplete connection
queue} che contiene un ingresso per ciascun socket per il quale è arrivato
- un SYN ma il three-way handshake non si è ancora concluso. Questi socket
+ un SYN ma il three way handshake non si è ancora concluso. Questi socket
sono tutti nello stato \texttt{SYN\_RECV}.
\item Una coda delle connessioni complete (\textit{complete connection queue}
- che contiene un ingresso per ciascun socket per il quale il three-way
+ che contiene un ingresso per ciascun socket per il quale il three way
handshake è stato completato ma ancora \texttt{accept} non è ritornata.
Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
\end{enumerate}
client il server crea una nuova entrata nella coda delle connessioni
incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà nella coda
delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad
-un timeout. Nel caso di completamento del three-way handshake l'entrata viene
+un timeout. Nel caso di completamento del three way handshake l'entrata viene
sostata nella coda delle connessioni complete. Quando il processo chiama la
funzione \texttt{accept} (vedi \secref{sec:TCPel_func_accept}) la prima
entrata nella coda delle connessioni complete è passata al programma, o, se la
massimo valore della somma del numero di entrate possibili per ciascuna di
dette code. Stevens riporta che BSD ha sempre applicato un fattore di 1.5 al
valore, e provvede una tabella con i risultati ottenuti con vari kernel,
-compreso linux 2.0, che mostrano le differenze fra diverse implementazioni.
+compreso Linux 2.0, che mostrano le differenze fra diverse implementazioni.
-In linux il significato di questo valore è cambiato a partire dal kernel
+In Linux il significato di questo valore è cambiato a partire dal kernel
2.2 per prevenire l'attacco chiamato \texttt{syn flood}. Questo si basa
sull'emissione da parte dell'attaccante di un grande numero di pacchetti SYN
indirizzati verso una porta forgiati con indirizzo IP fasullo\footnote{con la
\texttt{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
protezione dei syncookies però (con l'opzione da compilare nel kernel e da
attivare usando \texttt{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
-viene ignorato e non esiste più un valore massimo. In ogni caso in linux il
+viene ignorato e non esiste più un valore massimo. In ogni caso in Linux il
valore di \texttt{backlog} viene troncato ad un massimo di \texttt{SOMAXCONN}
-se è superiore a detta constante (che di default vale 128).
+se è superiore a detta costante (che di default vale 128).
La scelta storica per il valore di questo parametro è di 5, e alcuni vecchi
kernel non supportavano neanche valori superiori, ma la situazione corrente è
occupato fra chiamate successive alla \texttt{accept} (per cui la coda più
occupata sarebbe quella delle connessioni completate), ma piuttosto quello di
gestire la presenza di un gran numero di SYN in attesa di concludere il
-three-way handshake.
+three way handshake.
Infine va messo in evidenza che nel caso di socket TCP quando un SYN arriva
con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
condizione in cui le code sono piene è ovviamente transitoria, per cui se il
-client ristrasmette il SYN è probabile che passato un po' di tempo possa
+client ritrasmette il SYN è probabile che passato un po' di tempo possa
trovare nella coda lo spazio per una nuova connessione. Se invece si
rispondesse con un RST per indicare l'impossibilità di effettuare la
connessione la chiamata a \texttt{connect} nel client ritornerebbe con una
La funzione può essere usata solo con socket che supportino la connessione
(cioè di tipo \texttt{SOCK\_STREAM}, \texttt{SOCK\_SEQPACKET} o
\texttt{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
-esplicita della connessione, (attualmenente in linux solo DECnet ha questo
+esplicita della connessione, (attualmente in Linux solo DECnet ha questo
comportamento), la funzione opera solo l'estrazione dalla coda delle
connessioni, la conferma della connessione viene fatta implicitamente dalla
prima chiamata ad una \texttt{read} o una \texttt{write} mentre il rifiuto
della connessione viene fatto con la funzione \texttt{close}.
-E da chiarire che linux presenta un comportamento diverso nella gestione degli
+È da chiarire che Linux presenta un comportamento diverso nella gestione degli
errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
\texttt{accept} passa gli errori di rete pendenti sul nuovo socket come codici
di errore per \texttt{accept}. Inoltre la funzione non fa ereditare ai nuovi
socket descriptor non è più utilizzabile dal processo e non può essere usato
come argomento per una \texttt{write} o una \texttt{read} (anche se l'altro
capo della connessione non avesse chiuso la sua parte). Il kernel invierà
-comunque tutti i dati che ha in coda prima di inziare la sequenza di chiusura.
+comunque tutti i dati che ha in coda prima di iniziare la sequenza di chiusura.
Vedremo più avanti in \secref{sec:TCPadv_so_linger} come è possibile cambiare
questo comportamento, e cosa deve essere fatto perché il processo possa
immediatamente il socket \texttt{list\_fd}; mentre il padre continua ad
operare solo sul socket in ascolto chiudendo \texttt{sock\_fd} dopo ciascuna
\texttt{accept}. Per quanto abbiamo detto in \secref{sec:TCPel_func_close}
-queste due chiusure non causano l'innesco della sequenza di chiusura perchè il
+queste due chiusure non causano l'innesco della sequenza di chiusura perché il
numero di riferimenti non si è annullato.
Infatti subito dopo la creazione del socket \texttt{list\_fd} ha una
usualmente non chiama \texttt{bind}) per ottenere numero IP e porta locale
associati al socket restituito da una \texttt{connect}, o da un server che ha
chiamato \texttt{bind} su un socket usando 0 come porta locale per ottenere il
-numero di porta effiemera assegnato dal kernel.
+numero di porta effimera assegnato dal kernel.
Inoltre quando un server esegue una \texttt{bind} su un indirizzo generico, se
chiamata dopo il completamento di una connessione sul socket restituito da
directory.
Il nome completo di file generico è composto da una serie di questi
-\textsl{componenti} separati da una \texttt{/} (in linux più \texttt{/}
+\textsl{componenti} separati da una \texttt{/} (in Linux più \texttt{/}
consecutive sono considerate equivalenti ad una sola). Il nome completo di un
file viene usualmente chiamato \textit{pathname}, e anche se il manuale della
-glibc depreca questo nome (poichè genererebbe confusione, dato che con
+glibc depreca questo nome (poiché genererebbe confusione, dato che con
\textit{path} si indica anche un insieme di directory su cui effettuare una
ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune
che è senz'altro più chiaro dell'alternativa proposta.
Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
-seguito, vedi \secref{sec:proc_chroot}) è la stessa per tutti i processi ed
+seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
equivale alla directory radice dell'albero (come descritto in
\secref{sec:fileintr_overview}): in questo caso si parla di un pathname
\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
\subsection{Il funzionamento di un filesystem unix}
\label{sec:filedir_filesystem}
-Come già accennato in \secref{sec:fileintr_overview} linux (ed ogni unix in
+Come già accennato in \secref{sec:fileintr_overview} Linux (ed ogni unix in
generale) organizza i dati che tiene su disco attraverso l'uso di un
-filesystem. Una delle caratteristiche di linux rispetto agli altri unix è
+filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
quella di poter supportare grazie al VFS una enorme quantità di filesystem
diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
\caption{Organizzazione di un filesystem}
\label{fig:filedir_filesys_detail}
\end{figure}
-da questa figura si evidenzano alcune caratteristiche su cui è bene porre
+da questa figura si evidenziano alcune caratteristiche su cui è bene porre
attenzione in quanto sono fondamentali per capire il funzionamento delle
funzioni che manipolano i file e le directory su cui torneremo fra poco; in
particolare è opportuno ricordare sempre che:
Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
suole chiamare questo tipo di associazione un collegamento diretto (o
-\textit{hard link}). Il prototipo della funzione e le sue caratteritiche
+\textit{hard link}). Il prototipo della funzione e le sue caratteristiche
principali, come risultano dalla man page, sono le seguenti:
\begin{prototype}{unistd.h}
{int link(const char * oldpath, const char * newpath)}
Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
-filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
+filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
il caso ad esempio del filesystem \texttt{vfat} di windows).
La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti
programmi non sono in grado di gestire e la cui rimozione diventa estremamente
complicata (in genere occorre far girare il programma \texttt{fsck} per
-riparare il filesystem); data la sua pericolosità in linux questa
+riparare il filesystem); data la sua pericolosità in Linux questa
caratteristica è stata disabilitata, e la funzione restituisce l'errore
\texttt{EPERM}.
\subsection{Le funzioni \texttt{remove} e \texttt{rename}}
\label{sec:filedir_cre_canc}
-Al contrario di quanto avviene con altri unix in linux non è possibile usare
+Al contrario di quanto avviene con altri unix in Linux non è possibile usare
\texttt{unlink} sulle directory, per cancellare una directory si può usare la
funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
-tipo unix. Inoltre in linux non è consentito eseguire un link diretto ad una
+tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una
directory.
Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
\begin{prototype}{unistd.h}
{int readlink(const char * path, char * buff, size\_t size)}
- Legge il contnuto del link simbolico indicato da \texttt{path} nel buffer
+ Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
\texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
- piccolo pe contenerla.
+ piccolo per contenerla.
La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
\label{sec:filedir_chmod}
-\subsection{Il flag \texttt{stiky}}
-\label{sec:filedir_stiky}
+\subsection{Il flag \texttt{sticky}}
+\label{sec:filedir_sticky}
\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
\label{sec:filedir_chown}
\item \texttt{EACCESS}
Non c'è il permesso di scrittura per la directory in cui si vuole inserire
la nuova directory.
- \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
+ \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
\item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
- contiene troppi file. Sotto linux questo normalmente non avviene perchè il
+ contiene troppi file. Sotto Linux questo normalmente non avviene perché il
filesystem standard consente la creazione di un numero di file maggiore di
quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
fare anche con filesystem di altri sistemi questo errore può presentarsi.
\subsection{Accesso alle directory}
\label{sec:filedir_dir_read}
-Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
+Benché le directory siano oggetti del filesystem come tutti gli altri non ha
ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
poterne leggere il contenuto ad esempio per fare la lista dei file che esse
contengono o ricerche sui medesimi.
specificare un puntatore nullo come \textit{buffer}, nel qual caso la
stringa sarà allocata automaticamente per una dimensione pari a
\texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
- del pathname altrimenti. In questo caso si deve ricordare di disallocara la
+ del pathname altrimenti. In questo caso si deve ricordare di disallocare la
stringa una volta cessato il suo utilizzo.
La funzione restituisce il puntatore \texttt{buffer} se riesce,
è nullo.
\item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
lunghezza del pathname.
- \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
+ \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
componenti del pathname (cioè su una delle directory superiori alla
corrente).
\end{errlist}
Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
fatta per compatibilità all'indietro con BSD, che non consente di specificare
la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
-dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
-\secref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
+dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
+\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
funzione è deprecata.
\begin{prototype}{unistd.h}{int chdir (const char * pathname)}
Come dice il nome (che significa \textit{change directory}) questa funzione
- serve a cambiare la directory di lavoro a quella speficata dal pathname
+ serve a cambiare la directory di lavoro a quella specificata dal pathname
contenuto nella stringa \texttt{pathname}.
\end{prototype}
dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
cosiddetti file di dispositivo (i \textit{device files}). Questi sono dei file
speciali agendo sui quali i programmi possono leggere, scrivere e compiere
-operazioni direttamente sulle perferiche, usando le stesse funzioni che si
+operazioni direttamente sulle periferiche, usando le stesse funzioni che si
usano per i normali file di dati.
In questo capitolo forniremo un'introduzione alle principali caratteristiche
-di questa interfaccia, su come essa viene implementata in linux e su come sono
+di questa interfaccia, su come essa viene implementata in Linux e su come sono
organizzati i file nel sistema.
link, i socket e gli stessi i file di dispositivo (questi ultimi, per
convenzione, sono inseriti nella directory \texttt{/dev}).
-\subsection{Il \textit{virtual filesystem} di linux}
+\subsection{Il \textit{virtual filesystem} di Linux}
\label{sec:fileintr_vfs}
-Esamineremo adesso come viene implementato l'accesso ai files in linux. Questa
+Esamineremo adesso come viene implementato l'accesso ai files in Linux. Questa
sezione riporta informazioni sui dettagli di come il kernel gestisce i files,
ed è basata sul documento di Richard Goochs distribuito coi sorgenti del
-kernel (\texttt{linux/Documentation/vfs.txt}).
+kernel (nella directory \texttt{linux/Documentation/vfs.txt}).
L'argomento è abbastanza ``esoterico'' e questa sezione può essere saltata ad
una prima lettura; è bene però tenere presente che vengono introdotti qui
alcuni termini che potranno comparire in seguito, come \textit{inode},
\textit{dentry}, \textit{dcache}.
-In linux il concetto di \textit{everything is a file} è stato implementato
+In Linux il concetto di \textit{everything is a file} è stato implementato
attraverso il \textit{virtual filesystem} (da qui in avanti VFS) che è
l'interfaccia astratta che il kernel rende disponibile ai programmi in user
space attraverso la quale vengono manipolati i files; esso provvede anche
permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}). I
restanti tre bit sono usati per indicare alcune caratteristiche più complesse
(\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in
-seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_stiky}).
+seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un
processo cerca l'accesso al file esso controlla i propri uid e gid
VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
un flusso continuo di bytes; non esiste cioè differenza per come vengono visti
dal sistema file di diverso contenuto o formato (come nel caso di quella fra
-file di testo e binari che c'è in windows) né c'è una strutturazione a record
+file di testo e binari che c'è in Windows) né c'è una strutturazione a record
per il cosiddetto ``accesso diretto'' come nel caso del VMS.
% (con i kernel
% della serie 2.4 è disponibile una forma di accesso diretto ai dischi il
% \textit{raw access} che però non ha nulla a che fare con questo).
-Una seconda differenza è nel formato dei file ascii; in Unix la fine riga è
+Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
codificata in maniera diversa da Windows o MacIntosh, in particolare il fine
riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
-(\verb|\r|) del mac e del \texttt{CR LF} di windows. Questo può causare alcuni
+(\verb|\r|) del mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
problemi qualora si facciano assunzioni sul terminatore della riga.
usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
devono essere usati i file descriptor se si vuole ricorrere a modalità
speciali di I/O come il polling o il non-bloccante (vedi
-\secref{sec:file_bohhhhh}).
+\secref{sec:file_xxx}).
Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
dei file descriptor, che tratta tutti i file nello stesso modo, con
ogni processo avrà la sua posizione corrente nel file, che non sarà
influenzata da quello che altri processi possono fare. Anzi, aprire un file
significa appunto creare ed inizializzare una tale struttura, per cui se si
-apre due volte lo stesso file all'interno dello stesso processo, si otterrano
+apre due volte lo stesso file all'interno dello stesso processo, si otterranno
due file descriptor o due stream che avranno ancora una posizione corrente nel
file assolutamente indipendente.
-\chapter{I files: l'interfaccia standard C}
+\chapter{I files: l'interfaccia standard ANSI C}
\label{cha:files_std_interface}
%
il processo invia ordinariamente i dati in uscita. Normalmente è associato
dalla shell all'output del terminale e scrive sullo schermo.
\item \texttt{FILE * stderr} Lo \textit{standard input} cioè lo stream su cui
- il processo è supposto inviare i messaaggi di errore. Normalmente anch'esso
+ il processo è supposto inviare i messaggi di errore. Normalmente anch'esso
è associato dalla shell all'output del terminale e scrive sullo schermo.
\end{itemize}
\subsection{La funzione \texttt{fcntl}}
\label{sec:fileunix_fcntl}
-\subsection{La funzione \texttt{fcntl}}
+\subsection{La funzione \texttt{ioctl}}
\label{sec:fileunix_ioctl}
\chapter{Introduzione}
\label{cha:intro_unix}
-In questo primo capitolo sarà fatta un'introduzione ai contetti generali su
+In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
cui è basato un sistema di tipo unix, per fornire una base di comprensione
-mirata a sottolinearne le peculiarità che saranno poi importanti per quello
-che rigarda la programmazione; in particolare faremo una panoramica sulla
+mirata a sottolineare le peculiarità che saranno poi importanti per quello
+che riguarda la programmazione; in particolare faremo una panoramica sulla
struttura di un sistema \textit{unix-like} come Linux.
Chi avesse già una conoscenza di questa materia può tranquillamente saltare
\section{La struttura di un sistema Unix}
\label{sec:intro_unix_struct}
-Il concetto base di unix é quello di un nucleo del sistema (il cosiddetto
-\textit{kernel}) a cui si demanda la gestione delle risorse essenziali (la
-CPU, la memoria, le periferiche); mentre tutto il resto, quindi anche la parte
-che prevede l'interazione con l'utente, deve venire realizzato tramite
-programmi eseguiti dal kernel e che accedano alle risorse hardware tramite
-delle richieste a quest'ultimo.
+Il concetto base di un sistema unix-like é quello di un nucleo del sistema (il
+cosiddetto \textit{kernel}) a cui si demanda la gestione delle risorse
+essenziali (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi
+anche la parte che prevede l'interazione con l'utente, deve venire realizzato
+tramite programmi eseguiti dal kernel e che accedano alle risorse hardware
+tramite delle richieste a quest'ultimo.
Fin dall'inizio unix si presenta come un sistema operativo
-\textit{multitasking}, cioé in grado di eseguire contemporaneamente più
+\textit{multitasking}, cioè in grado di eseguire contemporaneamente più
programmi, e multiutente, in cui é possibile che più utenti siano connessi ad
una macchina eseguendo più programmi ``in contemporanea'' (in realtà, almeno
per macchine a processore singolo, i programmi vengono eseguiti singolarmente
%computer (e quindi per un uso personale), sui quali l'hardware (allora
%limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
-Gli unix più recenti, come linux, sono stati realizzati usando alcune
+Gli unix più recenti, come Linux, sono stati realizzati usando alcune
caratteristiche dei processori moderni come la gestione hardware della memoria
e la modalità protetta. In sostanza con i processori moderni si può
disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
zone di memoria fisica. Quello che succede é che il kernel é il solo
programma ad essere eseguito in modalità privilegiata, con il completo accesso
all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
-(e non possono accedere direttamente alle zone di memoria riservate, al kernel
+(e non possono accedere direttamente alle zone di memoria riservate
o alle porte di input/output).
Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, ad
intervalli fissi e sulla base di un opportuno calcolo delle priorità, quale
``processo'' (vedi \capref{cha:process}) deve essere posto in esecuzione (il
-cosidetto \textit{prehemptive scheduling}), e questo verrà comunque eseguito
-in modelità protetta; quando necessario il processo potrà accedere alle
+cosiddetto \textit{prehemptive scheduling}). Questo verrà comunque eseguito
+in modalità protetta; quando necessario il processo potrà accedere alle
risorse hardware soltanto attraverso delle opportune chiamate al sistema
(\textit{system call}) con un'interfaccia ben definita e standardizzata che
restituiranno il controllo al kernel.
La memoria viene sempre gestita del kernel attraverso il meccanismo della
memoria virtuale, che consente di assegnare a ciascun processo uno spazio di
-indirizzi ``virtuale'' che il kernel stesso, con l'ausilio della unità di
-gestione della memoria, si incaricherà di rimappare automaticamente sulla
-memoria disponibile, salvando su disco (nella cosiddetta \textit{swap}) quando
-necessario le pagine di memoria in eccedenza.
+indirizzi ``virtuale'' (vedi \secref{sec:proc_memory}) che il kernel stesso,
+con l'ausilio della unità di gestione della memoria, si incaricherà di
+rimappare automaticamente sulla memoria disponibile, salvando quando
+necessario su disco (nella cosiddetta \textit{swap}) le pagine di memoria in
+eccedenza.
Le periferiche infine vengono viste in genere attraverso un'interfaccia
-astratta che permette di trattarle come fossero file. secondo il concetto per
-cui \textit{everything is a file}, vedi \capref{cha:files_intro}, (questo
-non è vero per le interfacce di rete, ma resta valido il concetto generale che
-tutto il lavoro di accesso e gestione a basso livello è effettuato dal
-kernel), mentre ai programmi vengono fornite solo delle routine di
-interfacciamento; essendo l'argomento principale di cui tratteremo, di esse
-parleremo in abbondanza nei capitoli successivi.
+astratta che permette di trattarle come fossero file, secondo il concetto per
+cui \textit{everything is a file}, vedi \capref{cha:files_intro}, (questo non
+è vero per le interfacce di rete, che hanno un'interfaccia diversa, ma resta
+valido il concetto generale che tutto il lavoro di accesso e gestione a basso
+livello è effettuato dal kernel).
\section{User space e kernel space}
\label{sec:intro_userkernel}
-Questa architettura fa sì che nei sistemi unix esista una distinzione
-essenziale fra il cosiddetto \textit{user space}, che contraddistingue
-l'ambiente in cui vengono eseguiti i programmi, e il \textit{kernel space} che
-é l'ambiente in cui viene eseguito il kernel. Ogni programma gira come se
-avesse la piena disponibilità della macchina e della memoria ed è, salvo i
-meccanismi di comunicazione previsti dall'architettura (che esamineremo nel
-\capref{cha:IPC}) completamente ignaro del fatto che altri programmi possono
-essere messi in esecuzione dal kernel.
-
-In questo non è possibile ad un singolo programma disturbare l'azione di un
-altro programma o del sistema e questo è il principale motivo della stabilità
-di un sistema unix nei confronti di altri sistemi in cui i processi non hanno
-di questi limiti, o che vengono per vari motivi eseguiti al livello del
-kernel.
+L'architettura appena descritta fa sì che nei sistemi unix esista una
+distinzione essenziale fra il cosiddetto \textit{user space}, che
+contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
+\textit{kernel space} che é l'ambiente in cui viene eseguito il kernel. Ogni
+programma vede se stesso come se avesse la piena disponibilità della CPU
+e della memoria ed è, salvo i meccanismi di comunicazione previsti
+dall'architettura (che esamineremo nel \capref{cha:IPC}) completamente ignaro
+del fatto che altri programmi possono essere messi in esecuzione dal kernel.
+
+Per questa separazione non è possibile ad un singolo programma disturbare
+l'azione di un altro programma o del sistema e questo è il principale motivo
+della stabilità di un sistema unix nei confronti di altri sistemi in cui i
+processi non hanno di questi limiti, o che vengono per vari motivi eseguiti al
+livello del kernel.
Pertanto deve essere chiaro a chi programma in unix che l'accesso diretto
all'hardware non può avvenire se non all'interno del kernel, al di fuori dal
\label{sec:intro_kernandlib}
Per capire meglio la distinzione fra kernel space e user space si può prendere
-in esame la procedura di avvio di un sistema unix; all'avvio il bios (o in
-generale il software di avvio posto nelle eprom) eseguirà il \textit{boot}
-incarichandosi di caricare il kernel in memoria e di farne partire
+in esame la procedura di avvio di un sistema unix; all'avvio il BIOS (o in
+generale il software di avvio posto nelle EPROM) eseguirà il \textit{boot}
+incaricandosi di caricare il kernel in memoria e di farne partire
l'esecuzione; quest'ultimo, dopo aver inizializzato le periferiche farà
partire il primo processo, \textit{init} che è quello che si incaricherà di
far partire tutti i processi successivi, come quello che si occupa di
Questo significa ad esempio che il sistema di per sé non dispone di primitive
per tutta una serie di operazioni (come la copia di un file) che altri sistemi
-(come windows) hanno invece al loro interno. Per questo può capitare che
+(come Windows) hanno invece al loro interno. Per questo può capitare che
alcune operazioni, come quella in esempio, siano implementate come normali
programmi.
si aspetta da un sistema operativo.
Questo è importante anche dal punto di vista della programmazione, infatti
-programmare in linux significa anzitutto essere in grado di usare la Libreria
+programmare in Linux significa anzitutto essere in grado di usare la Libreria
Standard del C, in quanto né il kernel né il linguaggio C implementano
direttamente operazioni comuni come la gestione della memoria, l'input/output
o la manipolazione delle stringhe presenti in qualunque programma.
-Per questo in linux una parte essenziale del sistema (senza la quale nulla
+Per questo in GNU/Linux una parte essenziale del sistema (senza la quale nulla
funziona) è la realizzazione fatta dalla FSF della suddetta libreria (la
\textit{glibc}), in cui sono state implementate tutte le funzioni essenziali
definite negli standard POSIX e ANSI C, che viene utilizzata da qualunque
Il concetto base è quello di utente (\textit{user}) del sistema, utente che ha
dei ben definiti limiti e capacità rispetto a quello che può fare. Sono così
-previsti una serie di meccanismi per identificare i singoli utenti ed uan
+previsti una serie di meccanismi per identificare i singoli utenti ed una
serie di permessi e protezioni per impedire che utenti diversi possano
danneggiarsi a vicenda o danneggiare il sistema.
% Figure commands
%
\newcommand{\curfig}{fig.~\thefigure}
+
\newcommand{\nfig}{%
\setcounter{usercount}{\value{figure}}%
\addtocounter{usercount}{1}%
fig.~\thechapter.\theusercount}
+
\newcommand{\pfig}{%
\setcounter{usercount}{\value{figure}}%
\addtocounter{usercount}{-1}%
fig.~\thechapter.\theusercount}
+
\newcommand{\figref}[1]{fig.~\ref{#1}}
%
% Tables commands
%% GaPiL : Guida alla Programmazione in Linux
%%
%% S. Piccardi Feb. 2001
-%%
+%%
%% main.tex: file principale, gli altri vanno inclusi da questo.
%%
\documentclass[a4paper,11pt,twoside,italian]{book}
\chapter{Introduzione alla programmazione di rete}
\label{cha:network}
-In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
+In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
come prerequisiti per capire la programmazione di rete, per evitare un
capitolo puramente teorico partiremo con due semplici esempi per poi passare
ad un esame a grandi linee dei protocolli di rete e di come questi sono
In \nfig\ è riportata la sezione principale del codice del nostro client
elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richesta.
+restituisce l'ora locale della macchina a cui si effettua la richiesta.
\begin{figure}[!htb]
Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che
comprende il trattamento delle opzioni e una funzione per stampare un
messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
-può essere compilato su una qualunque macchina linux.
+può essere compilato su una qualunque macchina Linux.
Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
Usando la funzione \texttt{connect} sul socket creato in precedenza
(\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
-server specificato dall'indirizzo immesso nella struttura possata come secondo
+server specificato dall'indirizzo immesso nella struttura passata come secondo
argomento, il terzo argomento è la dimensione di detta struttura. Dato che
esistono diversi tipi di socket, si è dovuto effettuare un cast della
struttura inizializzata in precedenza, che è specifica per i socket IPv4. Un
Il tutto è inserito in un loop infinito (\texttt{\small 42--55}) in modo da
poter ripetere l'invio della data ad una successiva connessione.
-È impostante notare che questo server è estremamente elementare, infatti a
+È importante notare che questo server è estremamente elementare, infatti a
parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
\begin{figure}[!htbp]
\centering
- \caption{Struttura a livelli dei protocolli OSi e TCP/IP, con la
- relative corrispondeze e la divisione fra kernel e user space.}
+ \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la
+ relative corrispondenze e la divisione fra kernel e user space.}
\label{fig:net_osi_tcpip_comp}
\end{figure}
device driver \& scheda di interfaccia \\
\hline
\end{tabular}
-\caption{I quattro livelli del protocollo TPC/IP.}
+\caption{I quattro livelli del protocollo TCP/IP.}
\label{tab:net_layers}
\end{table}
\begin{description}
\item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
- genere questi vengono realizzati secondo il modello Client-Server (vedi
+ genere questi vengono realizzati secondo il modello client-server (vedi
\secref{sec:net_cliserv}.
\item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
terminali su cui girano gli applicativi, regola il flusso delle
quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
-svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
+svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
protocollo di trasporto sia questo.
Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
rientra in quanto trattato qui.
In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
-concentrandoci per le ragioni esposte sul livello di trasposto. All'interno di
+concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di
questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
nella maggior parte delle applicazioni.
Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
-vari prottocolli della famiglia, e delle loro relazioni reciproche e con
+vari protocolli della famiglia, e delle loro relazioni reciproche e con
alcune dalle principali applicazioni che li usano.
\begin{figure}[!htbp]
\begin{list}{}{}
\item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
- cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione
+ cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione
dei pacchetti TCP, UDP, ICMP e IGMP.
\item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
\item la semplificazione del formato della testata, eliminando o rendendo
opzionali alcuni dei campi di IPv4, per eliminare la necessità di
riprocessamento della stessa da parte dei router e contenere l'aumento di
- dimensione dovuto all'ampiamento degli indirizzi
+ dimensione dovuto all'ampliamento degli indirizzi
\item un supporto per le opzioni migliorato, per garantire una trasmissione
più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
delle opzioni, e la flessibilità necessaria per introdurne di nuove in
\subsection{UDP: User Datagram Protocol)}
\label{sec:net_udp}
-UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
+UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
in cui un client può scrivere su uno stesso socket pacchetti destinati a
-server diversi, o un server ricevere su un socket paccetti provenienti da
+server diversi, o un server ricevere su un socket pacchetti provenienti da
client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
stazioni usando la stessa frequenza.
velocità, ma la ricerca della massima affidabilità possibile nella
trasmissione dei dati.
-La prima differenza con UDP è che TCP provvede sempre una conessione diretta
+La prima differenza con UDP è che TCP provvede sempre una connessione diretta
fra un client e un server, attraverso la quale essi possono comunicare; per
questo il paragone più appropriato per questo protocollo è quello del
collegamento telefonico, in quanto prima viene stabilita una connessione fra
cioè specifica sempre all'altro capo della trasmissione quanti dati può
ricevere tramite una \textit{advertised window} (letteralmente finestra
annunciata), che indica lo spazio disponibile nel buffer di ricezione,
-cosicchè nella trasmissione non vengano inviati più dati di quelli che possono
+cosicché nella trasmissione non vengano inviati più dati di quelli che possono
essere ricevuti.
Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
conto che non è affatto detto che la \textit{path MTU} sia la stessa in
-entrambe le direzioni, perchè l'instradamento può essere diverso nei due
+entrambe le direzioni, perché l'instradamento può essere diverso nei due
sensi, con diverse tipologie di rete coinvolte.
Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
-un messaggio di errore ICMPv6 di tipo \textit{paket too big}.
+un messaggio di errore ICMPv6 di tipo \textit{packet too big}.
Dato che il meccanismo di frammentazione e riassemblaggio comporta
inefficienza normalmente viene utilizzato il procedimento della \textit{path
- MTU discover} (vedi RFC1191 per IPv4 e RFC1981 per IPv6) che permette dui
+ MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di
trovare il \textit{path MTU} fra due stazioni; per la realizzazione del
procedimento si usa il flag DF di IPv4 e il comportamento normale di IPv6
-inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC1191
-per IPv4 e l'RFC1981 per IPv6) fintanto che non si hanno più errori.
+inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC~1191
+per IPv4 e l'RFC~1981 per IPv6) fintanto che non si hanno più errori.
Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
Questo progetto mira alla stesura di un libro il più completo e chiaro
possibile sulla programmazione in GNU/Linux (che da qui in avanti spesso
-chiameremo semplicemante linux per brevità). Ovviamente essendo i concetti in
+chiameremo semplicemante Linux per brevità). Ovviamente essendo i concetti in
gran parte gli stessi, esso dovrebbe restare valido anche per la
programmazione in ambito Unix generico, pur restando l'intenzione di
approfondire in maniera specifica le caratteristiche peculiari di GNU/Linux.
\textsl{filoni} di esecuzione (i cosiddetti \textit{thread}), o questo possa
essere composto da moduli multipli completamente separati, quando questo sarà
posto in esecuzione esso apparirà al sistema come un solo processo (il
-discorso dei \textit{thread} comunque in linux necessita di una trattazione a
+discorso dei \textit{thread} comunque in Linux necessita di una trattazione a
parte per la peculiarità dell'implementazione).
\section{La funzione \texttt{main}}
carica le librerie condivise che servono al programma, effettua il link
dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver
specificato il flag \texttt{-static} durante la compilazione, tutti i
-programmi in linux sono incompleti e necessitano di essere linkati alle
+programmi in Linux sono incompleti e necessitano di essere linkati alle
librerie condivise quando vengono avviati. La procedura è controllata da
alcune variabili di ambiente e dal contenuto di \texttt{/etc/ld.so.conf}, i
dettagli sono riportati nella man page di \texttt{ld.so}.
si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso
linker darebbe luogo ad errori.
-Lo stadard ISO C specifica che la funzione \texttt{main} può o non avere
+Lo standard ISO C specifica che la funzione \texttt{main} può o non avere
argomenti o prendere due argomenti che rappresentano gli argomenti passati da
linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
\begin{verbatim}
valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
maniera esplicita detta funzione.
-Una altra convenzione riserva i valori da 128 in sù per usi speciali, ad
+Una altra convenzione riserva i valori da 128 in su per usi speciali, ad
esempio 128 viene usato per indicare l'incapacità di eseguire un altro
programma in un sottoprocesso. Benché anche questa convenzione non sia
universalmente seguita è una buona idea tenerne conto.
uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in
cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In
\texttt{stdlib.h} sono definite due macro \texttt{EXIT\_SUCCESS} e
-\texttt{EXIT\_FAILURE}, che in linux sono poste rispettivamente ai valori 0 e
+\texttt{EXIT\_FAILURE}, che in Linux sono poste rispettivamente ai valori 0 e
1 (di tipo \texttt{int}), seguendo lo standard POSIX.
Infine occorre distinguere fra lo stato di uscita di un programma
Allo stesso modo l'unico modo in cui un programma può concludere
volontariamente la sua esecuzione è attraverso una chiamata alla system call
-\texttt{\_exec} sia esplicitamnte o che in maniera indiretta attraverso l'uso
+\texttt{\_exec} sia esplicitamente o che in maniera indiretta attraverso l'uso
di \texttt{exit} o il ritorno della funzione \texttt{main}.
Lo schema delle modalità con cui si avvia e conclude normalmente un programma
Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
-linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
+Linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
memoria viene vista dal punto di vista di un programma in esecuzione in un
processo.
Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
di basso livello dipendono in maniera diretta dall'architettura
-dell'hardware), ma quello più tipico, usato da unix (e da linux) è quello di
+dell'hardware), ma quello più tipico, usato da unix (e da Linux) è quello di
assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
-linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
+Linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
kernel 2.4 il limite è stato esteso).
Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
-corrisponde all'effettiva posizione dei dati nella ram del computer; in genere
+corrisponde all'effettiva posizione dei dati nella RAM del computer; in genere
detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
utilizzabili e/o utilizzati).
macchine a 32 bit e 8kb sulle alpha, valori strettamente connessi all'hardware
di gestione della memoria) di dimensione fissa, e ciascuna pagina della
memoria virtuale è associata ad un supporto che può essere una pagina di
-memoria reale o ad un dipositivo di stoccaggio secondario (in genere lo spazio
+memoria reale o ad un dispositivo di stoccaggio secondario (in genere lo spazio
disco riservato alla swap, o i file che contengono il codice).
Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
diverse pagine di memoria virtuale appartenenti a processi diversi (come
accade in genere per le pagine che contengono il codice delle librerie
-condivise). Ad esempio il codice della fuzione \texttt{printf} starà su una
+condivise). Ad esempio il codice della funzione \texttt{printf} starà su una
sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
virtuale di tutti i processi hanno detta funzione nel loro codice.
reale avviene quello che viene chiamato un \textit{page fault}, l'hardware di
gestione della memoria (la MMU del processore) genera una interruzione e passa
il controllo al kernel il quale sospende il processo e si incarica di mettere
-in ram la pagina richiesta (effettuando tutte le operazioni necessarie per
+in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
reperire lo spazio necessario), per poi restituire il controllo al
processo.
trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili
in memoria. L'unica differenza avvertibile è quella dei tempi di esecuzione,
che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più
-lunghi, dovuti all'intervento del kernel. Normalemente questo è il prezzo da
+lunghi, dovuti all'intervento del kernel. Normalmente questo è il prezzo da
pagare per avere un multitasking reale, ed in genere il sistema è molto
efficiente in questo lavoro; quando però ci siano esigenze specifiche di
prestazioni è possibile usare delle funzioni che permettono di bloccare il
commette quando si è manipolato male un puntatore e genera quello che viene
chiamato un \textit{segmentation fault}, si tenta cioè di leggere e scrivere
da un indirizzo per il quale non esiste una associazione della pagina virtuale
-ed il kernel riponde al relativo \textit{page fault} mandando un segnale
+ed il kernel risponde al relativo \textit{page fault} mandando un segnale
\texttt{SIGSEGV} al processo, che normalmente ne causa la terminazione
immediata.
È pertanto importante capire come viene strutturata la memoria virtuale di un
processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
-indirizzi virtuali ai quali il processo può accedere. Storicamente un
+indirizzi virtuali ai quali il processo può accedere. Solitamente un
programma C viene suddiviso nei seguenti segmenti:
\begin{enumerate}
\item Il segmento di testo (\textit{text segment}). Contiene il codice
- macchina del programma e le costanti statiche. Normalente viene condiviso
+ macchina del programma e le costanti statiche. Normalmente viene condiviso
così che più processi (anche diversi nel caso di librerie) possano
- utilizzarlo e marcato in sola lettura per evitare sovrascritture accidentali
- (o maliziose) che ne modifichino le istruzioni.
+ utilizzarlo e viene marcato in sola lettura per evitare sovrascritture
+ accidentali (o maliziose) che ne modifichino le istruzioni.
Viene allocato da \texttt{exec} all'avvio del programma e resta invariato
per tutto il tempo dell'esecuzione.
-\item Il segmento dei dati (\textit{data segment}). Contiene le varibili
+\item Il segmento dei dati (\textit{data segment}). Contiene le variabili
globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
diviso in due parti.
- La prima è il segmento dei dati inizializzati, che contiene le variabili
- globali il cui valore è stato assegnato esplicitamente. Ad esempio se si
- definisce:
+ La prima parte è il segmento dei dati inizializzati, che contiene le
+ variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
+ se si definisce:
\begin{verbatim}
double pi = 3.14;
\end{verbatim}
segmento viene preallocato dalla \texttt{exec} e inizializzata ai valori
specificati.
- La seconda è il segmento dei dati non inizializzati, che contiene le
+ La seconda parte è il segmento dei dati non inizializzati, che contiene le
variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
esempio se si definisce:
\begin{verbatim}
int vect[100];
\end{verbatim}
questo valore sarà immagazzinato in questo segmento. Anch'esso viene
- allocato all'avvio, e tutte le varibili vengono inizializzate a
+ allocato all'avvio, e tutte le variabili vengono inizializzate a
zero (ed i puntatori a \texttt{NULL}).
Storicamente questo segmento viene chiamato BBS (da \textit{block started by
programma.
-\subsection{La librerie condivise}
-\label{sec:proc_mem_shlib}
+\subsection{Allocazione della memoria per i programmi C}
+\label{sec:proc_mem_alloc}
+
+Il C supporta due tipi di allocazione della memoria, l'allocazione statica è
+quella in cui vanno le variabili globali e le variabili statiche (e viene
+effettuata nel segmento dei dati), lo spazio per queste variabili viene
+allocati all'avvio del programma (come parte delle operazioni svolte da
+\texttt{exec}) e non viene liberato fino alla sua conclusione.
+
+L'allocazione automatica è quella che avviene per le cosiddette variabili
+automatiche, cioè gli argomenti delle funzioni o le variabili locali. Lo
+spazio per queste variabili viene allocato nello stack quando viene eseguito
+comando di invocazione della funzione e liberato quando si esce dalla
+medesima.
+
+Esiste però un terzo tipo di allocazione, che non è prevista dal linguaggio C,
+che è l'allocazione dinamica della memoria, necessaria quando il quantitativo
+di memoria che serve è determinabile solo in corso di esecuzione del
+programma.
+Il C non consente di usare variabili allocate dinamicamente, non è possibile
+cioè definire in fase di programmazione una variabile le cui dimensioni
+possano essere modificate durante l'esecuzione del programma; però le librerie
+del C forniscono una serie opportuna di funzioni per permettere l'allocazione
+dinamica di spazio in memoria (in genere nello heap, usando la system call
+\texttt{sbrk}), solo che a questo punto sarà possibile usarlo solo in maniera
+indiretta attraverso dei puntatori.
+
+Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
+quattro, i prototipi sono i seguenti:
+\begin{prototype}{stdlib.h}{void *calloc(size\_t size)}
+ Alloca \texttt{size} bytes nello heap. La memoria viene inizializzata a 0.
+
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \texttt{NULL} in caso di fallimento, nel qual caso
+ \texttt{errno} viene settata a \texttt{ENOMEM}.
+\end{prototype}
+\begin{prototype}{stdlib.h}{void *malloc(size\_t size)}
+ Alloca \texttt{size} bytes nello heap. La memoria non viene inizializzata.
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \texttt{NULL} in caso di fallimento, nel qual caso
+ \texttt{errno} viene settata a \texttt{ENOMEM}.
+\end{prototype}
+\begin{prototype}{stdlib.h}{void free(void *ptr)}
+ Disalloca lo spazio di memoria puntato da \texttt{ptr}.
+
+ La funzione non ritorna nulla.
+\end{prototype}
+\begin{prototype}{stdlib.h}{void *realloc(void *ptr, size\_t size)}
+ Cambia la dimensione del blocco allocato all'indirizzo \texttt{ptr}
+ portandola a \texttt{size}.
+
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \texttt{NULL} in caso di fallimento, nel qual caso
+ \texttt{errno} viene settata a \texttt{ENOMEM}.
+\end{prototype}
+
+Il puntatore che le funzioni di allocazione ritornano è garantito essere
+sempre correttamente allineato per tutti i tipi di dati; ad esempio sulle
+macchine a 32 bit in genere è allineato a multipli di 4 bytes e sulle macchine
+a 64 bit a multipli di 8 bytes. Il puntatori ritornati sono di tipo generico
+così non è necessario effettuare un cast per assegnarli a puntatori di altro
+tipo.
-\subsection{Allocazione e disallocazione della memoria}
-\label{sec:proc_mem_alloc}
+
+
+
\section{La gestione di parametri e opzioni}
individuare le parole viene usato come separatore lo spazio (comportamento
modificabile attraverso il settaggio della variabile di ambiente IFS).
-Nella scansione viene costruito l'array di puntatori \texttt{argv} inserendo
+Nella scansione viene costruito il vettore di puntatori \texttt{argv} inserendo
in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
variabile \texttt{argc} viene inizializzata al numero di parametri trovati, in
questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
le opzioni, queste ultime sono standardizzate per essere riconosciute come
tali: un elemento di \texttt{argv} che inizia con \texttt{-} e che non sia un
singolo \texttt{-} o \texttt{--} viene considerato un'opzione. In in genere
-le opzioni sono costituite da un lettera preceduta dal meno e possono avere o
+le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
no un parametro associato; un comando tipico può essere cioè qualcosa del
tipo:
\begin{verbatim}
Quando la funzione trova un'opzione essa ritorna il valore numerico del
carattere, in questo modo si possono prendere le azioni relative usando un
-case; la funzione inizializza inoltre alcune varibili globali:
+case; la funzione inizializza inoltre alcune variabili globali:
\begin{itemize}
\item \texttt{char * optarg} contiene il puntatore alla stringa argomento
dell'opzione.
\item \texttt{int optopt} contiene il carattere dell'opzione non riconosciuta.
\end{itemize}
-In \nfig è mostrato un programma di esempio,
-
+In \nfig\ è mostrato un programma di esempio,
\begin{figure}[htbp]
\footnotesize
versione estesa di \texttt{getopt}.
+
\subsection{Le variabili di ambiente}
\label{sec:proc_env_var}
\label{sec:prochand_control}
Esamineremo in questa sezione le varie funzioni per il controllo dei processi:
-la lore creazione, la terminazione, l'esecuzione di altri programmi. Prima di
+la loro creazione, la terminazione, l'esecuzione di altri programmi. Prima di
trattare in dettaglio le singole funzioni, faremo un'introduzione generale ai
-contetti che stanno alla base della gestione dei processi in unix.
+concetti che stanno alla base della gestione dei processi in unix.
\subsection{Una panoramica}
\label{sec:prochand_control_overview}
I processi vengono creati dalla funzione \texttt{fork}; in genere questa è una
-system call, ma linux però usa un'altra nomenclatura, e la funzione fork è
+system call, ma Linux però usa un'altra nomenclatura, e la funzione fork è
basata a sua volta sulla system call \texttt{clone}, che viene usata anche per
generare i \textit{thread}. Il processo figlio creato dalla \textit{fork} è
una copia identica del processo processo padre, solo che ha un suo pid
sistema ad esso associate vengono rilasciate.
Avere due processi che eseguono esattamente lo stesso codice non è molto
-utile, mormalmente si genera un secondo processo per affidagli l'esecuzione di
+utile, normalmente si genera un secondo processo per affidargli l'esecuzione di
un compito specifico (ad esempio gestire una connessione dopo che questa è
stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
questo si usa la seconda funzione fondamentale per programmazione coi processi
\label{sec:prochand_perms}
Va messo qui tutta la storia su effective, real, saved uid, e pure le cose di
-linux come il filesystem uid.
+Linux come il filesystem uid.
\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
\label{sec:prochand_setuid}
\subsubsection{Segnali di errore di programma}
Questi segnali sono generati quando il sistema, o in certi casi direttamente
-l'hardware (come per i page fault non valildi) rileva un qualche errore
+l'hardware (come per i page fault non validi) rileva un qualche errore
insanabile nel programma in esecuzione. In generale la generazione di questi
segnali significa che il programma ha dei gravi problemi (ad esempio ha
dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
% aritmetiche e richiede che esse siano notificate.
\item \texttt{SIGILL} Il nome deriva da \textit{illegal instruction},
significa che il programma sta cercando di eseguire una istruzione
- privilegiata od inesistente, in generale del codice illegale. Poiché il
+ privilegiata o inesistente, in generale del codice illegale. Poiché il
compilatore del C genera del codice valido si ottiene questo segnale se il
- file eseguibile è corrotto o si stanno cercando di eseguire dei
- dati. Quest'ultimo caso può accadere quando si passa un puntatore sbagliato
- al posto di un puntatore a funzione, o si eccede la scrittura di un array di
+ file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
+ Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
+ posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
- generato in caso di overflow dello stack o di problemi nell'esecuzione di
- di un signal handler.
+ generato in caso di overflow dello stack o di problemi nell'esecuzione di di
+ un signal handler.
\item \texttt{SIGSEGV} Il nome deriva da \textit{segment violation}, e
significa che il programma sta cercando di leggere o scrivere in una zona di
accorge dell'errore ed il kernel genera il segnale.
È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
- inizializzatoo leggendo al di la della fine di un vettore.
+ inizializzato leggendo al di la della fine di un vettore.
\item \texttt{SIGBUS}
\item \texttt{SIGABRT}
A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
\texttt{AF\_} da \textit{address family}, e che identifica il formato degli
-indirizzi usati in quel dominio; le man pages di linux si riferiscono a questi
+indirizzi usati in quel dominio; le man pages di Linux si riferiscono a questi
anche come \textit{name space}, (nome che però il manuale della glibc riserva
ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
nomi sono equivalenti e corrispondono agli stessi valori.
I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
-indirizzi sono definiti dall'header \textit{socket.h}. In linux le famiglie di
+indirizzi sono definiti dall'header \textit{socket.h}. In Linux le famiglie di
protocolli disponibili sono riportate in \ntab.
\begin{table}[htb]
PF\_APPLETALK & Appletalk & ddp(7) \\
PF\_PACKET & Low level packet interface & packet(7) \\
\end{tabular}
- \caption{Famiglie di protocolli definiti in linux}
+ \caption{Famiglie di protocolli definiti in Linux}
\label{tab:net_pf_names}
\end{table}
Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
esempio in generale tutti i socket di tipo \texttt{SOCK\_RAW} possono essere
-creati solo da processi che hanno i provilegi di root (cioè effective uid
+creati solo da processi che hanno i privilegi di root (cioè effective uid
uguale a zero) o la capability \texttt{CAP\_NET\_RAW}.
La scelta di un dominio non comporta però la scelta dello stile di
comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
-scegliere lo stile di comunicazione indicando il tipo di socket; linux e le
+scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le
glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
glibc chiama \textit{styles}) definiti come \texttt{int} in \texttt{socket.h}:
occorrerà eseguire un casting del relativo puntatore.
I tipi di dati che compongono la struttura sono stabiliti dallo standard
-Posix.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
+POSIX.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
definiti; la struttura è invece definita nell'include file
\texttt{sys/socket.h}
\hline
\end{tabular}
\caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
- stabilito dallo standard Posix.1g}
+ stabilito dallo standard POSIX.1g}
\label{tab:sock_data_types}
\end{table}
In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
aggiuntivo \texttt{uint8\_t sin\_len} (come riportato da R. Stevens nei suoi
libri). Questo campo non verrebbe usato direttamente dal programmatore e non è
-richiesto dallo standard Posix.1g, in linux pertanto non sussiste. Il campo
+richiesto dallo standard POSIX.1g, in Linux pertanto non sussiste. Il campo
\texttt{sa\_family\_t} era storicamente un \texttt{unsigned short}.
Dal punto di vista del programmatore l'unico uso di questa struttura è quello
attraverso internet; la struttura per gli indirizzi per un socket internet
(IPv4) è definita come \texttt{sockaddr\_in} nell'header file
\texttt{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
-conforme allo standard Posix.1g.
+conforme allo standard POSIX.1g.
\begin{figure}[!htbp]
Il membro \texttt{sin\_addr} contiene l'indirizzo internet dell'altro capo
della comunicazione, e viene acceduto sia come struttura (un resto di una
-implementazione precedente in cui questa era una union usata per accedere alle
+implementazione precedente in cui questa era una \texttt{union} usata per accedere alle
diverse classi di indirizzi) che come intero.
Infine è da sottolineare che sia gli indirizzi che i numeri di porta devono
Il campo \texttt{sin6\_family} deve essere sempre settato ad
\texttt{AF\_INET6}, il campo \texttt{sin6\_port} è analogo a quello di IPv4 e
-segue le stesse regole; il campo \texttt{sin6\_flowinfo} è a dua volta diviso
+segue le stesse regole; il campo \texttt{sin6\_flowinfo} è a sua volta diviso
in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i
successivi 4 bit la priorità e gli ultimi 4 sono riservati; questi valori
fanno riferimento ad alcuni campi specifici dell'header dei pacchetti IPv6
\subsection{La \textit{endianess}}
\label{sec:sock_endianess}
-La rappresentazione di un numbero binario in un computer può essere fatta in
+La rappresentazione di un numero binario in un computer può essere fatta in
due modi, chiamati rispettivamente \textit{big endian} e \textit{little
endian} a seconda di come i singoli bit vengono aggregati per formare le
variabili intere (in diretta corrispondenza a come sono poi in realtà cablati
per lo stesso motivo \textit{big endian}.
La \textit{endianess} di un computer dipende essenzialmente dalla architettura
-hardware usata; intel e digital usano il little endian, motorola, ibm, sun
+hardware usata; Intel e Digital usano il little endian, Motorola, IBM, Sun
(sostanzialmente tutti gli altri) usano il big endian. Il formato della rete è
-anch'esso big endian. Esistono poi anche dei processori che possono scegliere
-il tipo di formato all'avvio e alcuni, come il PowerPC o l'intel i860, possono
-pure passare da un tipo all'altro con una specifica istruzione; in ogni caso
-in linux l'ordinamanento è definito dall'archiettura e anche se questi
-cambiamenti sono possibili anche dopo che il sistema è avviato, non vengono
-mai eseguiti.
+anch'esso big endian, quello del bus PCI è little endian, quello del bus VME è
+big endian.
+
+Esistono poi anche dei processori che possono scegliere il tipo di formato
+all'avvio e alcuni, come il PowerPC o l'Intel i860, possono pure passare da un
+tipo di ordinamento all'altro con una specifica istruzione; in ogni caso in
+Linux l'ordinamento è definito dall'architettura e anche se questi cambiamenti
+sono possibili anche dopo che il sistema è avviato, non vengono mai eseguiti.
\subsection{Le funzioni per il riordinamento}
\label{sec:sock_func_ord}
di architettura all'altra i dati vengono interpretati in maniera diversa, e ad
esempio nel caso dell'intero a 16 bit ci si ritroverà con i due bytes in cui è
suddiviso scambiati di posto, e ne sarà quindi invertito l'ordine di lettura
-per cui, per riavere il valore originale dovrenno essere rovesciati.
+per cui, per riavere il valore originale dovranno essere rovesciati.
Per questo motivo si usano le seguenti funzioni di conversione che servono a
tener conto automaticamente della possibile differenza fra l'ordinamento usato
quello della rete.
\end{prototype}
\begin{prototype}{netinet/in.h}
-{unsigned sort int htons(unsigned short int hostshort)}
+{unsigned short int htons(unsigned short int hostshort)}
Converte l'intero a 16 bit \texttt{hostshort} dal formato della macchina a
quello della rete.
\end{prototype}
Un secondo insieme di funzioni di manipolazione serve per passare dal formato
binario usato nelle strutture degli indirizzi alla rappresentazione dei numeri
-IP che si usa normalente.
+IP che si usa normalmente.
Le prime tre funzioni di manipolazione riguardano la conversione degli
indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
projects / gapil.git / commitdiff