X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=socket.tex;h=a5af5da4c88f1f5fb8a0c8ecd3c2498b5f2c8505;hp=a563c353642d1992a69f543386539f36c0d9db4e;hb=96e11f1878552c4c4f245448e9dc6d66e1658542;hpb=f43b330570ece41d80aaca3c775eb4b7835aab28 diff --git a/socket.tex b/socket.tex index a563c35..a5af5da 100644 --- a/socket.tex +++ b/socket.tex @@ -8,7 +8,7 @@ operativi. Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo come creare un socket e come collegarlo allo specifico protocollo di rete che -utilizzerà per la comunicazione. Per evitare una introduzione puramente teorica +utilizzerà per la comunicazione. Per evitare un'introduzione puramente teorica concluderemo il capitolo con un primo esempio di applicazione. \section{Una panoramica} @@ -22,14 +22,15 @@ con essi. \label{sec:sock_socket_def} Il \textit{socket}\footnote{una traduzione letterale potrebbe essere - \textsl{manicotto}, ma essendo universalmente noti come socket utilizzeremo - sempre la parola inglese} è uno dei principali meccanismi di comunicazione -fra programmi utilizzato in ambito unix. Il socket costituisce in sostanza un + \textsl{presa}, ma essendo universalmente noti come socket utilizzeremo + sempre la parola inglese.} è uno dei principali meccanismi di comunicazione +fra programmi utilizzato in ambito Unix. Il socket costituisce in sostanza un canale di comunicazione fra due processi su cui si possono leggere e scrivere -dati analogo a quello di una pipe ma a differenza di questa e degli altri -meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati -alla comunicazione fra processi che girano sulla stessa macchina ma possono -effettuare la comunicazione anche attraverso la rete. +dati analogo a quello di una pipe (vedi \secref{sec:ipc_pipes}) ma a +differenza di questa e degli altri meccanismi esaminati nel capitolo +\capref{cha:IPC} i socket non sono limitati alla comunicazione fra processi +che girano sulla stessa macchina ma possono effettuare la comunicazione anche +attraverso la rete. Quella dei socket costituisce infatti la principale API (\textit{Application Program Interface}) usata nella programmazione di rete. La loro origine @@ -37,8 +38,8 @@ risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché siano state sviluppate interfacce alternative, originate dai sistemi SVr4, come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la -diffusione e la popolarità di quella dei socket (né tantomeno usabilità e -flessibilità). +diffusione e la popolarità di quella dei socket (né tantomeno la stessa +usabilità e flessibilità). La flessibilità e la genericità dell'interfaccia inoltre ha consentito di utilizzare i socket con i più disparati meccanismi di comunicazione, e non @@ -57,11 +58,11 @@ usato, le funzioni da usare restano le stesse. Per questo motivo una semplice descrizione dell'interfaccia è assolutamente inutile, in quanto il comportamento di quest'ultima e le problematiche da -affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione -usato. La scelta di questo stile va infatti ad incidere sulla semantica che -verrà utilizzata a livello utente per gestire la comunicazione (su come -inviare e ricevere i dati) e sul comportamento effettivo delle funzioni -utilizzate. +affrontare cambiano radicalmente a seconda dello \textsl{stile} di +comunicazione usato. La scelta di questo stile va infatti ad incidere sulla +semantica che verrà utilizzata a livello utente per gestire la comunicazione +(su come inviare e ricevere i dati) e sul comportamento effettivo delle +funzioni utilizzate. La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni stili di @@ -115,7 +116,7 @@ socket, per cui viene messo a zero (con l'eccezione dei \textit{raw socket}). Apre un socket. \bodydesc{La funzione restituisce un intero positivo se riesce, e -1 se - fallisce, in quest'ultimo caso la variabile \var{errno} è settata con i + fallisce, in quest'ultimo caso la variabile \var{errno} è impostata con i seguenti codici di errore: \begin{errlist} @@ -148,9 +149,10 @@ altro nome con cui si indicano i domini. 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 -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. +indirizzi usati in quel dominio; le pagine di manuale di Linux si riferiscono +a questi anche come \textit{name space}, (nome che però il manuale delle +\acr{glibc} riserva ai domini) e che identifica il formato degli indirizzi +usati in quel dominio. L'idea alla base della distinzione era che una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si @@ -162,7 +164,7 @@ 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 -protocolli disponibili sono riportate in \ntab. +protocolli disponibili sono riportate in \tabref{tab:net_pf_names}. \begin{table}[htb] \footnotesize @@ -175,7 +177,7 @@ protocolli disponibili sono riportate in \ntab. \macro{PF\_UNIX}, \macro{PF\_LOCAL} & Local communication & unix(7) \\ \macro{PF\_INET} & IPv4 Internet protocols & ip(7) \\ - \macro{PF\_INET6} & IPv6 Internet protocols & \\ + \macro{PF\_INET6} & IPv6 Internet protocols & ipv6(7) \\ \macro{PF\_IPX} & IPX - Novell protocols & \\ \macro{PF\_NETLINK}& Kernel user interface device & netlink(7) \\ \macro{PF\_X25} & ITU-T X.25 / ISO-8208 protocol & x25(7) \\ @@ -191,8 +193,8 @@ protocolli disponibili sono riportate in \ntab. Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere -creati solo da processi che hanno i privilegi di root (cioè effective uid -uguale a zero) o la capability \macro{CAP\_NET\_RAW}. +creati solo da processi che hanno i privilegi di root (cioè con userid +effettivo uguale a zero) o con la capability \macro{CAP\_NET\_RAW}. \subsection{Il tipo, o stile} @@ -202,8 +204,9 @@ La scelta di un dominio non comporta per 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 -glibc mettono a disposizione i seguenti tipi di socket (che il manuale della -glibc chiama \textit{styles}) definiti come \type{int} in \file{socket.h}: +\acr{glibc} mettono a disposizione i seguenti tipi di socket (che il manuale +della \acr{glibc} chiama \textit{styles}) definiti come \ctyp{int} in +\file{socket.h}: \begin{list}{}{} \item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati @@ -225,10 +228,10 @@ glibc chiama \textit{styles}) definiti come \type{int} in \file{socket.h}: \item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato. \end{list} -Si tenga presente che non tutte le combinazioni di famiglia di protocolli e -tipo di socket sono valide, in quanto non è detto che nella famiglia esista un -protocollo per tutti gli stili di comunicazione indicati qui sopra. Una -tabella che mostra le combinazioni valide è la seguente: +Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli +e un tipo di socket sono valide, in quanto non è detto che in una famiglia +esista un protocollo per ciascuno dei diversi stili di comunicazione appena +elencati. \begin{table}[htb] \footnotesize @@ -266,9 +269,11 @@ tabella che mostra le combinazioni valide \label{tab:sock_sock_valid_combinations} \end{table} -Dove per ogni combinazione valida si è indicato il tipo di protocollo, o la -parola \textsl{si} qualora non il protocollo non abbia un nome definito, -mentre si sono lasciate vuote le caselle per le combinazioni non supportate. +In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni +valide possibili per le varie famiglie di protocolli. Per ogni combinazione +valida si è indicato il tipo di protocollo, o la parola \textsl{si} qualora +non il protocollo non abbia un nome definito, mentre si sono lasciate vuote le +caselle per le combinazioni non supportate. @@ -300,10 +305,10 @@ attraverso puntatori (cio maneggiare puntatori a strutture relative a tutti gli indirizzi possibili nelle varie famiglie di protocolli; questo pone il problema di come passare questi puntatori, il C ANSI risolve questo problema coi i puntatori generici -(i \type{void *}), ma l'interfaccia dei socket è antecedente alla -definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire -una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata -in \nfig: +(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla definizione +dello standard ANSI, e per questo nel 1982 fu scelto di definire una struttura +generica per gli indirizzi dei socket, \type{sockaddr}, che si è riportata in +\figref{fig:sock_sa_gen_struct}. \begin{figure}[!htb] \footnotesize @@ -323,9 +328,9 @@ invocano dette funzioni passando l'indirizzo di un protocollo specifico 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 -definiti; la struttura è invece definita nell'include file -\file{sys/socket.h} +POSIX.1g, riassunti in \tabref{tab:sock_data_types} con i rispettivi file di +include in cui sono definiti; la struttura è invece definita nell'include file +\file{sys/socket.h}. \begin{table}[!htb] \centering @@ -345,16 +350,16 @@ definiti; la struttura \hline \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\ \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di - un socket& \type{sys/socket.h}\\ + un socket& \file{sys/socket.h}\\ \hline - \type{in\_addr\_t} & indirizzo IPv4 (\file{uint32\_t}) & - \type{netinet/in.h}\\ - \type{in\_port\_t} & porta TCP o UDP (\file{uint16\_t})& - \type{netinet/in.h}\\ + \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & + \file{netinet/in.h}\\ + \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& + \file{netinet/in.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} @@ -362,13 +367,13 @@ In alcuni sistemi la struttura aggiuntivo \var{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 esiste. Il campo -\type{sa\_family\_t} era storicamente un \type{unsigned short}. +\type{sa\_family\_t} era storicamente un \ctyp{unsigned short}. Dal punto di vista del programmatore l'unico uso di questa struttura è quello di fare da riferimento per il casting, per il kernel le cose sono un po' diverse, in quanto esso usa il puntatore per recuperare il campo \var{sa\_family} con cui determinare il tipo di indirizzo; per questo -motivo, anche se l'uso di un puntatore \type{void *} sarebbe più immediato +motivo, anche se l'uso di un puntatore \ctyp{void *} sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto l'uso di questa struttura. @@ -379,8 +384,8 @@ l'uso di questa struttura. I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione attraverso internet; la struttura per gli indirizzi per un socket internet (IPv4) è definita come \type{sockaddr\_in} nell'header file -\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig, -conforme allo standard POSIX.1g. +\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in +\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g. \begin{figure}[!htb] \footnotesize @@ -405,14 +410,14 @@ internet di un'interfaccia pi prevede numeri di porta, che sono utilizzati solo dai protocolli di livello superiore come TCP e UDP. Questa struttura però viene usata anche per i socket RAW che accedono direttamente al livello di IP, nel qual caso il numero della -porta viene settato al numero di protocollo. +porta viene impostato al numero di protocollo. -Il membro \var{sin\_family} deve essere sempre settato; \var{sin\_port} +Il membro \var{sin\_family} deve essere sempre impostato; \var{sin\_port} specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; i numeri di porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da -servizi standard. Soltanto processi con i privilegi di root (effective uid -uguale a zero) o con la capability \macro{CAP\_NET\_BIND\_SERVICE} possono -usare la funzione \func{bind} su queste porte. +servizi standard. Soltanto processi con i privilegi di root (con userid +effettivo uguale a zero) o con la capability \macro{CAP\_NET\_BIND\_SERVICE} +possono usare la funzione \func{bind} su queste porte. Il membro \var{sin\_addr} contiene l'indirizzo internet dell'altro capo della comunicazione, e viene acceduto sia come struttura (un resto di una @@ -430,7 +435,7 @@ problema e le relative soluzioni). \subsection{La struttura degli indirizzi IPv6} \label{sec:sock_sa_ipv6} -Essendo IPv6 una estensione di IPv4 i socket di tipo \macro{PF\_INET6} sono +Essendo IPv6 un'estensione di IPv4 i socket di tipo \macro{PF\_INET6} sono sostanzialmente identici ai precedenti; la parte in cui si trovano praticamente tutte le differenze è quella della struttura degli indirizzi. La struttura degli indirizzi è definita ancora in \file{netinet/in.h}. @@ -455,7 +460,7 @@ struct in6_addr { \label{fig:sock_sa_ipv6_struct} \end{figure} -Il campo \var{sin6\_family} deve essere sempre settato ad +Il campo \var{sin6\_family} deve essere sempre impostato ad \macro{AF\_INET6}, il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole; il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i @@ -606,7 +611,7 @@ I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare l'ordinamento usato sulla rete (da \textit{network order}) e la lettera \texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da \textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad -indicare i tipi di dato (\type{long} o \type{short}, riportati anche dai +indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai prototipi). Usando queste funzioni si ha la conversione automatica: nel caso in cui la @@ -676,7 +681,7 @@ e \textit{numeric}. Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di indirizzo e può essere \macro{AF\_INET} o \macro{AF\_INET6}. Se la famiglia -indicata non è valida entrambe le funzioni settano la variabile \var{errno} +indicata non è valida entrambe le funzioni impostano la variabile \var{errno} al valore \macro{EAFNOSUPPORT}. I prototipi delle suddette funzioni sono i seguenti: \begin{prototype}{sys/socket.h} @@ -698,7 +703,7 @@ seguenti: \bodydesc{La funzione restituisce un puntatore non nullo a \var{dest} in caso di successo e un puntatore nullo in caso di fallimento, in - quest'ultimo caso viene settata la variabile \var{errno} con il valore + quest'ultimo caso viene impostata la variabile \var{errno} con il valore \macro{ENOSPC} in caso le dimensioni dell'indirizzo eccedano la lunghezza specificata da \var{len} o \macro{ENOAFSUPPORT} in caso \var{af} non sia una famiglia di indirizzi valida.} @@ -835,9 +840,10 @@ successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire definizioni precise e dettagli di funzionamento che saranno trattati estensivamente più avanti. -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 richiesta. +In \figref{fig:net_cli_code} è 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 +richiesta. \begin{figure}[!htb] \footnotesize @@ -912,7 +918,7 @@ Il primo passo (\texttt{\small 14--18}) socket in tutte le chiamate successive. Nel caso la chiamata fallisca si stampa un errore con la relativa routine e si esce. -Il passo seguente (\texttt{\small 19--27}) è quello di costruire una apposita +Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita struttura \type{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed il numero della porta del servizio. Il primo passo è inizializzare tutto a zero, per poi inserire il tipo di protocollo e la porta (usando per @@ -957,7 +963,7 @@ necessario deve provvedere il programma stesso. Dopo aver illustrato il client daremo anche un esempio di un server elementare, in grado di rispondere al precedente client. Il listato è -nuovamente mostrato in \nfig, il sorgente completo +nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella directory \file{sources}. @@ -1069,3 +1075,8 @@ scritto per essere lanciato da linea di comando, se lo si volesse utilizzare come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell attiva e il terminale da cui lo si è lanciato è stato sconnesso), occorrerebbero delle opportune modifiche. + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: