X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=78a6ce446664057d26eecd33fc6de8ea8f8fc65f;hp=aaa79147d819a60c1c9cebb0bbb6f027a09547e7;hb=9a6d19e384fe9b1afbe4d9124ac34eaf7aa57562;hpb=bf81ce9ec539254693a8c41641a99af1aa1d886f diff --git a/tcpsock.tex b/tcpsock.tex index aaa7914..78a6ce4 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -86,12 +86,12 @@ si stabilisce la connessione. % Una analogia citata da R. Stevens per la connessione TCP è quella con il -% sistema del telefono. La funzione \texttt{socket} può essere considerata -% l'equivalente di avere un telefono. La funzione \texttt{bind} è analoga al -% dire alle altre persone qual'è il proprio numero di telefono perché possano -% chiamare. La funzione \texttt{listen} è accendere il campanello del telefono -% per sentire le chiamate in arrivo. La funzione \texttt{connect} richiede di -% conoscere il numero di chi si vuole chiamare. La funzione \texttt{accept} è +% sistema del telefono. La funzione \func{socket} può essere considerata +% l'equivalente di avere un telefono. La funzione \func{bind} è analoga al +% dire alle altre persone qual è il proprio numero di telefono perché possano +% chiamare. La funzione \func{listen} è accendere il campanello del telefono +% per sentire le chiamate in arrivo. La funzione \func{connect} richiede di +% conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è % quando si risponde al telefono. \begin{figure}[htb] @@ -271,7 +271,7 @@ passiva stato \texttt{LISTEN} in cui vengono accettate le connessioni. Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione -chiama la funzione \texttt{close} prima di aver ricevuto un +chiama la funzione \func{close} prima di aver ricevuto un \textit{end-of-file} (chiusura attiva) la transizione è verso lo stato \texttt{FIN\_WAIT\_1}; se invece l'applicazione riceve un FIN nello stato \texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato @@ -461,17 +461,17 @@ dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su internet (una versione aggiornata si può trovare all'indirizzo -\texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}); inoltre +\href{ftp://ftp.isi.edu/in-notes/iana/assignements/port-number} +{\texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}}); inoltre in un sistema unix-like un analogo elenco viene mantenuto nel file \file{/etc/services}, con la corrispondenza fra i vari numeri di porta ed il nome simbolico del servizio. I numeri sono divisi in tre intervalli: -\begin{enumerate} -\item \textsl{le porte conosciute}. I numeri da 0 a 1023. Queste sono - controllate e assegnate dalla IANA. Se è possibile la stessa porta è - assegnata allo stesso servizio sia su UDP che su TCP (ad esempio la porta 22 - è assegnata a SSH su entrambi i protocolli, anche se viene usata solo dal - TCP). +\begin{enumerate*} +\item \textsl{le porte note}. I numeri da 0 a 1023. Queste sono controllate e + assegnate dalla IANA. Se è possibile la stessa porta è assegnata allo stesso + servizio sia su UDP che su TCP (ad esempio la porta 22 è assegnata a SSH su + entrambi i protocolli, anche se viene usata solo dal TCP). \item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non sono controllate dalla IANA, che però registra ed elenca chi usa queste @@ -483,29 +483,36 @@ nome simbolico del servizio. I numeri sono divisi in tre intervalli: \item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a 65535. La IANA non dice nulla riguardo a queste porte che pertanto sono i candidati naturali ad essere usate come porte effimere. -\end{enumerate} +\end{enumerate*} In realtà rispetto a quanto indicato nell'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} i vari sistemi hanno fatto scelte diverse per le porte effimere, in particolare in -fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD 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. +fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux. \begin{figure}[!htb] \centering - \includegraphics[width=15cm]{img/port_alloc} + \includegraphics[width=13cm]{img/port_alloc} \caption{Allocazione dei numeri di porta.} \label{fig:TCP_port_alloc} \end{figure} I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che corrispondono alle porte con numero minore di 1024 e coincidono quindi con le -porte conosciute). La loro caratteristica è che possono essere assegnate a un -socket solo da un processo con i privilegi di amministratore, per far si che -solo l'amministratore possa allocare queste porte per far partire i relativi -servizi. +\textsl{porte note}). La loro caratteristica è che possono essere assegnate a +un socket solo da un processo con i privilegi di amministratore, per far sì +che solo l'amministratore possa allocare queste porte per far partire i +relativi servizi. + +Le \textsl{glibc} definiscono (in \texttt{netinet/in.h}) +\const{IPPORT\_RESERVED} e \const{IPPORT\_USERRESERVED}, in cui la prima (che +vale 1024) indica il limite superiore delle porte riservate, e la seconda (che +vale 5000) il limite inferiore delle porte a disposizione degli utenti. La +convenzione vorrebbe che le porte \textsl{effimere} siano allocate fra questi +due valori. Nel caso di Linux questo è vero solo in uno dei due casi di +fig.~\ref{fig:TCP_port_alloc}, e la scelta fra i due possibili intervalli +viene fatta dinamicamente dal kernel a seconda della memoria disponibile per +la gestione delle relative tabelle. Si tenga conto poi che ci sono alcuni client, in particolare \cmd{rsh} e \cmd{rlogin}, che richiedono una connessione su una porta riservata anche dal @@ -641,7 +648,7 @@ precedente in sez.~\ref{sec:sock_socket}. La funzione \funcd{bind} assegna un indirizzo locale ad un socket.\footnote{nel nostro caso la utilizzeremo per socket TCP, ma la funzione è generica e deve essere usata per qualunque tipo di socket - \texttt{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata + \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata cioè per specificare la prima parte dalla socket pair. Viene usata sul lato server per specificare la porta (e gli eventuali indirizzi locali) su cui poi ci si porrà in ascolto. Il prototipo della funzione è il seguente: @@ -754,10 +761,10 @@ staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}. La funzione \funcd{connect} è usata da un client TCP per stabilire la connessione con un server TCP,\footnote{di nuovo la funzione è generica e supporta vari tipi di socket, la differenza è che per socket senza - connessione come quelli di tipo \texttt{SOCK\_DGRAM} la sua chiamata si + connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati - e ricevuti i pacchetti, mentre per socket di tipo \texttt{SOCK\_STREAM} o - \texttt{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del + e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o + \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del TCP il \index{\textit{three~way~handshake}}\textit{three way handshake}) della connessione.} il prototipo della funzione è il seguente: \begin{prototype}{sys/socket.h} @@ -864,8 +871,8 @@ necessario effettuare una \func{bind}. La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè, come dice il nome, per metterlo in ascolto di eventuali connessioni;\footnote{questa funzione può essere usata con socket che - supportino le connessioni, cioè di tipo \texttt{SOCK\_STREAM} o - \texttt{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare + supportino le connessioni, cioè di tipo \const{SOCK\_STREAM} o + \const{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare il socket dallo stato \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in un server dopo le chiamate a \func{socket} e \func{bind} e prima della chiamata ad \func{accept}. Il prototipo della funzione, come @@ -992,8 +999,8 @@ trasparente dal protocollo TCP. La funzione \funcd{accept} è chiamata da un server per gestire la connessione una volta che sia stato completato il \textit{three way handshake},\footnote{la funzione è comunque generica ed è utilizzabile su - socket di tipo \texttt{SOCK\_STREAM}, \texttt{SOCK\_SEQPACKET} e - \texttt{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su + socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} e + \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su cui si potrà operare per effettuare la comunicazione. Se non ci sono connessioni completate il processo viene messo in attesa. Il prototipo della funzione è il seguente: @@ -1182,7 +1189,7 @@ ritornata da \func{accept}), all'esecuzione di \func{exec} verr memoria l'immagine del programma eseguito, che a questo punto perde ogni riferimento ai valori tornati da \func{accept}. Il socket descriptor però resta aperto, e se si è seguita una opportuna convenzione per rendere noto al -programma eseguito qual'è il socket connesso, \footnote{ad esempio il solito +programma eseguito qual è il socket connesso, \footnote{ad esempio il solito \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername} per determinare l'indirizzo remoto del client. @@ -1406,7 +1413,7 @@ marcare dei blocchi di dati, per cui se questo programma stesso. Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene - fornito direttamente dal \textsl{superdemone} \texttt{inetd}, pertanto basta + fornito direttamente dal \textsl{superdemone} \cmd{inetd}, pertanto basta assicurarsi che esso sia abilitato nel relativo file di configurazione.} possiamo verificare il funzionamento del nostro client, avremo allora: \begin{verbatim} @@ -1593,7 +1600,7 @@ Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si provvede anche (\texttt{\small 40--43}) a stampare sullo standard output l'indirizzo e la porta da cui il client ha effettuato la connessione, usando i valori contenuti nelle strutture restituite da \func{accept}, eseguendo le -opportune conversioni con \func{inet\_ntop} e \func{atohs}. +opportune conversioni con \func{inet\_ntop} e \func{ntohs}. Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo non si sia gestita né la terminazione del processo né il suo uso come demone, @@ -1705,7 +1712,7 @@ sez.~\ref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo automaticamente l'invio multiplo qualora una singola \func{write} non sia sufficiente. I dati vengono riletti indietro (\texttt{\small 7}) con una \func{read}\footnote{si è fatta l'assunzione implicita che i dati siano - contenuti tutti in un solo segmento, così che la chiamata a \texttt{read} li + contenuti tutti in un solo segmento, così che la chiamata a \func{read} li restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer questo sarà sempre vero, vedremo più avanti come superare il problema di rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} sul @@ -2285,9 +2292,10 @@ attraverso la sequenza vista in sez.~\ref{sec:TCP_conn_term}, per cui la \func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si modifichi il client per fargli gestire l'invio di un segmento di RST alla -chiusura dal socket (come suggerito da Stevens in \cite{UNP1}), non si ha -nessun errore al ritorno di \funcd{accept}, quanto un errore di -\errcode{ECONNRESET} al primo tentativo di accesso al socket. +chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi +sez.~\ref{sec:sock_options_main}), non si ha nessun errore al ritorno di +\func{accept}, quanto un errore di \errcode{ECONNRESET} al primo tentativo di +accesso al socket. @@ -3250,7 +3258,7 @@ che ci servir connessioni o di dati in arrivo, e processarli immediatamente. Per implementare lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il programma usa una tabella dei socket connessi mantenuta nel vettore -\var{fd\_open} dimensionato al valore di \macro{FD\_SETSIZE}, ed una variabile +\var{fd\_open} dimensionato al valore di \const{FD\_SETSIZE}, ed una variabile \var{max\_fd} per registrare il valore più alto dei file descriptor aperti. Prima di entrare nel ciclo principale (\texttt{\small 6--56}) la nostra