\subsection{Il modello \textit{client-server}}
\label{sec:net_cliserv}
-Il concetto fondamentale su cui si basa la programmazione di rete sotto Linux
-(e sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server}, riceve una richiesta e risponde a
-un programma di utilizzo, il \textit{client}, fornendo a quest'ultimo un
-definito insieme di servizi.
-
-Infatti seguono questo modello tutti i servizi fondamentali di internet, come
-il le pagine web, ftp, telnet, ssh e praticamente ogni servizio che viene
-fornito tramite la rete, anche se, come abbiamo visto, il modello è utilizzato
-in generale anche per programmi che, come gli esempi che abbiamo usato in
-\capref{cha:IPC} a proposito della comunicazione fra processi nello stesso
-sistema, non fanno necessariamente uso della rete.
+L'architettura fondamentale su cui si basa gran parte della programmazione di
+rete sotto Linux (e sotto Unix in generale) è il modello
+\textit{client-server} caratterizzato dalla presenza di due categorie di
+soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
+richieste e forniscono le risposte, ed i programmi di utilizzo, detti
+\textit{client}.
+
+In generale un server può (di norma deve) essere in grado di rispondere a più
+di un client, per cui è possibile che molti programmi possano interagire
+contemporaneamente, quello che contraddistingue il modello però è che
+l'architettura dell'interazione è sempre nei termini di molti verso uno, il
+server, che viene ad assumere un ruolo privilegiato.
+
+Seguono questo modello tutti i servizi fondamentali di internet, come le
+pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
+servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
+modello è utilizzato in generale anche per programmi che, come gli esempi che
+abbiamo usato in \capref{cha:IPC} a proposito della comunicazione fra processi
+nello stesso sistema, non fanno necessariamente uso della rete.
Normalmente si dividono i server in due categorie principali, e vengono detti
\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
-
Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
-occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
-la richiesta. Una volta completata la richiesta il server diventa di nuovo
-disponibile.
+occupato e non rispondendo ad ulteriori richieste fintanto che non ha fornito
+una risposta alla richiesta. Una volta completata la risposta il server
+diventa di nuovo disponibile.
Un \textsl{server concorrente} al momento di trattare la richiesta crea un
-processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
-attesa di ulteriori richieste. In questo modo più richieste possono essere
-soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
-il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
+processo figlio (o un thread) incaricato di fornire i servizi richiesti, per
+porsi immediatamente in attesa di ulteriori richieste. In questo modo, con
+sistemi multitasking, più richieste possono essere soddisfatte
+contemporaneamente. Una volta che il processo figlio ha concluso il suo lavoro
+esso di norma viene terminato, mentre il server originale resta sempre attivo.
-\subsection{Il modello \textit{peer-to-perr}}
+\subsection{Il modello \textit{peer-to-peer}}
\label{sec:net_peertopeer}
-Da fare
+Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
+è quello della preminenza del server rispetto ai client, le architetture
+\textit{peer-to-peer} si basano su un approccio completamente opposto che è
+quello di non avere nessun programma che svolga un ruolo preminente.
+
+Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
+in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
+ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
+la separazione netta dei compiti che si ritrova nelle archietetture
+\textit{client-server}.
+
+Le architetture \textit{peer-to-peer} sono salite alla ribalta con
+l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
+buon esempio di archietetture \textit{peer-to-peer}, in cui ciascun nodo,
+tramite il demone che gestisce il routing, richiede ed invia informazioni ad
+altri nodi.
+
+In realtà in molti casi di archietture classificate come \textit{peer-to-peer}
+non è detto che la struttura sia totalmente paritetica e ci sono parecchi
+esempi in cui alcuni servizi vengono centralizzati o disribuiti
+gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
+effettuate su un server centrale.
+
+
\subsection{Il modello \textit{three-tier}}
\label{sec:net_three_tier}
-Da fare
+Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
+una estensione del modello \textit{client-server}. Con il crescere della
+quantità dei servizi forniti in rete (in particolare su internet) ed al numero
+di accessi richiesto. Si è così assistito anche ad una notevole crescita di
+complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
+
+In particolare sempre più spesso si assiste ad una integrazione di servizi di
+database con servizi di web, in cui le pagine vengono costruite dinamicamente
+sulla base dei dati contenuti nel database. In tutti questi casi il problema
+fondamentale di una architettura \textit{client-server} è che la richiesta di
+un servizio da parte di un gran numero di client si scontra con il collo di
+bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
+scalabilità.
+
+Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
+talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
+carico delle richieste su più server identici, mantenendo quindi
+sostanzialmente inalterata l'archiettettura \textit{client-server} originale.
+
+Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
+servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
+inefficienza dell'uso delle risorse. Il problema è particolarmente grave per i
+database che non possono essere replicati e sincronizzati facilemente, e che
+sono molto onerosi sia in termini di richiesta risorse.
+
+È a partire da queste problematiche che nasce il modello \textit{three-tier},
+che si struttura, come dice il nome, su tre livelli. Il primo, quello dei
+client, che eseguono le richieste e gestiscono l'interfaccia con l'utente,
+resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
+parte server viene suddivisa in due livelli, introducendo un
+\textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
+richieste dei client per ottimizzare l'accesso al terzo livello, quello dei
+server che invece si limita a fornire dei dati che verranno usati dal
+\textit{middle-tier} per eseguire le operazioni.
+
\section{I protocolli di rete}
\begin{figure}[!htbp]
\centering
- \includegraphics[width=15cm]{img/tcpip_overview}
+ \includegraphics[width=13cm]{img/tcpip_overview}
\caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
\label{fig:net_tcpip_overview}
\end{figure}
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}{l|c|c|c|c|c|}
- \multicolumn{1}{c}{} &\multicolumn{1}{c}{\const{SOCK\_STREAM}}&
- \multicolumn{1}{c}{\const{SOCK\_DGRAM}} &
- \multicolumn{1}{c}{\const{SOCK\_RAW}} &
- \multicolumn{1}{c}{\const{SOCK\_PACKET}}&
- \multicolumn{1}{c}{\const{SOCK\_SEQPACKET}} \\
- \cline{2-6}
+ \begin{tabular}{|l|c|c|c|c|c|}
+ \hline
+ \multicolumn{1}{|c|}{\textbf{Famiglia}}&
+ \multicolumn{5}{|c|}{\textbf{Tipo}}\\
+ \hline
+ \hline
+ &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}&
+ \const{SOCK\_PACKET}&\const{SOCK\_SEQPACKET} \\
+ \hline
\const{PF\_UNIX} & si & si & & & \\
- \cline{2-6}
+ \hline
\const{PF\_INET} & TCP & UDP & IPv4 & & \\
- \cline{2-6}
+ \hline
\const{PF\_INET6} & TCP & UDP & IPv6 & & \\
- \cline{2-6}
+ \hline
\const{PF\_IPX} & & & & & \\
- \cline{2-6}
+ \hline
\const{PF\_NETLINK} & & si & si & & \\
- \cline{2-6}
+ \hline
\const{PF\_X25} & & & & & si \\
- \cline{2-6}
+ \hline
\const{PF\_AX25} & & & & & \\
- \cline{2-6}
+ \hline
\const{PF\_ATMPVC} & & & & & \\
- \cline{2-6}
+ \hline
\const{PF\_APPLETALK} & & si & si & & \\
- \cline{2-6}
+ \hline
\const{PF\_PACKET} & & si & si & & \\
- \cline{2-6}
+ \hline
\end{tabular}
\caption{Combinazioni valide di dominio e tipo di protocollo per la
funzione \func{socket}.}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct sockaddr_in {
sa_family_t sin_family; /* address family: AF_INET */
- u_int16_t sin_port; /* port in network byte order */
+ in_port_t sin_port; /* port in network byte order */
struct in_addr sin_addr; /* internet address */
};
/* Internet address. */
struct in_addr {
- u_int32_t s_addr; /* address in network byte order */
+ in_addr_t s_addr; /* address in network byte order */
};
\end{lstlisting}
\end{minipage}
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct sockaddr_in6 {
- u_int16_t sin6_family; /* AF_INET6 */
- u_int16_t sin6_port; /* port number */
- u_int32_t sin6_flowinfo; /* IPv6 flow information */
+ uint16_t sin6_family; /* AF_INET6 */
+ in_port_t sin6_port; /* port number */
+ uint32_t sin6_flowinfo; /* IPv6 flow information */
struct in6_addr sin6_addr; /* IPv6 address */
- u_int32_t sin6_scope_id; /* Scope id (new in 2.4) */
+ uint32_t sin6_scope_id; /* Scope id (new in 2.4) */
};
struct in6_addr {
- unsigned char s6_addr[16]; /* IPv6 address */
+ uint8_t s6_addr[16]; /* IPv6 address */
};
\end{lstlisting}
\end{minipage}
chiamati \textit{local domain} o anche \textit{Unix domain}); essi rispetto ai
precedenti possono essere anche creati in maniera anonima attraverso la
funzione \func{socketpair} (vedi \secref{sec:ipc_socketpair}). Quando però si
-vuole fare riferimento esplicito ad uno di questi socket si deve usare la
-seguente struttura di indirizzi definita nel file di header \file{sys/un.h}.
+vuole fare riferimento esplicito ad uno di questi socket si deve usare una
+struttura degli indirizzi di tipo \struct{sockaddr\_un}, la cui definizione si
+è riportata in \secref{fig:sock_sa_local_struct}.
\begin{figure}[!htb]
\footnotesize \centering
};
\end{lstlisting}
\end{minipage}
- \caption{La struttura degli indirizzi dei socket locali
- \structd{sockaddr\_un}.}
+ \caption{La struttura degli indirizzi dei socket locali (detti anche
+ \textit{unix domain}) \structd{sockaddr\_un} definita in \file{sys/un.h}.}
\label{fig:sock_sa_local_struct}
\end{figure}
In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
-il campo \var{sun\_path} deve specificare un indirizzo; questo ha due forme:
+il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme:
un file (di tipo socket) nel filesystem o una stringa univoca (mantenuta in
uno spazio di nomi astratto). Nel primo caso l'indirizzo viene specificato
come una stringa (terminata da uno zero) corrispondente al pathname del file;
-nel secondo invece \var{sun\_path} inizia con uno zero vengono usati i
-restanti byte come stringa (senza terminazione).
+nel secondo invece \var{sun\_path} inizia con uno zero e vengono usati i
+restanti byte come stringa, senza terminazione.
\subsection{La struttura degli indirizzi AppleTalk}
AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
-opportuno usare le funzioni di libreria, si tratta qui questo argomento
-principalmente per mostrare l'uso di un protocollo alternativo.
+opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
+questo argomento principalmente per mostrare l'uso di un protocollo
+alternativo.
I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
per \param{protocol} è \func{ATPROTO\_DDP}.
+Gli indirizzi AppleTalk devono essere specificati tramite una struttura
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
+\figref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo il
+file \file{netatalk/at.h}.
+
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct sockaddr_atalk {
sa_family_t sat_family; /* address family */
- u_char sat_port; /* port */
+ uint8_t sat_port; /* port */
struct at_addr sat_addr; /* net/node */
};
struct at_addr {
- unsigned short s_net;
- unsigned char s_node;
+ uint16_t s_net;
+ uint8_t s_node;
};
\end{lstlisting}
\end{minipage}
\label{fig:sock_sa_atalk_struct}
\end{figure}
-Il campo \var{sut\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
-campo \var{sun\_port} specifica la porta che identifica i vari servizi. Valori
+Il campo \var{sat\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
+campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
usati solo da processi con i privilegi di amministratore o con la capability
\const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
-struttura \var{sun\_addr}, e deve essere in \textit{network order}; esso è
+struttura \var{sat\_addr}, e deve essere in \textit{network order}; esso è
composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
valore \const{AT\_ANYNET}, che indica una rete genrica e vale anche per
indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
rete.
-
-
-
-
-\subsection{La struttura degli indirizzi DECnet}
-\label{sec:sock_sa_decnet}
-
-I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
-Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
-fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è di
-compatibilità con macchine che stanno comunque scomparendo. Lo si riporta solo
-come esempio
+%% \subsection{La struttura degli indirizzi DECnet}
+%% \label{sec:sock_sa_decnet}
+
+%% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
+%% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
+%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
+%% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
+%% solo come esempio
projects / gapil.git / commitdiff
