From: Simone Piccardi Date: Sat, 8 Mar 2003 15:36:56 +0000 (+0000) Subject: Nuovo overview dei protocolli. Scritto qualcosa su peer-to-peer e three-tier X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=5c31faf40cb22faf707e6dc3b16770ae64fe5b4d Nuovo overview dei protocolli. Scritto qualcosa su peer-to-peer e three-tier --- diff --git a/img/gapil.jpg b/img/gapil.jpg deleted file mode 100644 index cdf8a7e..0000000 Binary files a/img/gapil.jpg and /dev/null differ diff --git a/img/tcpip_overview.dia b/img/tcpip_overview.dia index 4f2436e..26b2254 100644 Binary files a/img/tcpip_overview.dia and b/img/tcpip_overview.dia differ diff --git a/network.tex b/network.tex index 606a330..d564dc4 100644 --- a/network.tex +++ b/network.tex @@ -47,43 +47,107 @@ gli scopi del testo approfondire questi argomenti. \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} @@ -317,7 +381,7 @@ reciproche e con alcune dalle principali applicazioni che li usano. \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} diff --git a/socket.tex b/socket.tex index 5a2a8ea..2dc5674 100644 --- a/socket.tex +++ b/socket.tex @@ -278,33 +278,35 @@ elencati. \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}.} @@ -437,12 +439,12 @@ si usa IPv4) \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} @@ -497,15 +499,15 @@ in \figref{fig:sock_sa_ipv6_struct}. \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} @@ -540,8 +542,9 @@ comunicazione fra processi che stanno sulla stessa macchina (per vengono 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 @@ -554,18 +557,18 @@ struct sockaddr_un { }; \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} @@ -576,8 +579,9 @@ I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria 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 @@ -585,19 +589,24 @@ 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} @@ -606,12 +615,12 @@ struct at_addr { \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 @@ -619,18 +628,14 @@ pu 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