X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=78a6ce446664057d26eecd33fc6de8ea8f8fc65f;hp=27f96ef930fa10b01a0e8df787fe2edfa37c7ae2;hb=9a6d19e384fe9b1afbe4d9124ac34eaf7aa57562;hpb=c293b5306e2be6b5db7a685ab6fbcd9036e053ba diff --git a/tcpsock.tex b/tcpsock.tex index 27f96ef..78a6ce4 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -1,6 +1,6 @@ %% tcpsock.tex %% -%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -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 @@ -930,7 +937,7 @@ connessione completa. \label{fig:TCP_listen_backlog} \end{figure} -Storicamente il valore del parametro \param{backlog} era corrispondente al +Storicamente il valore dell'argomento \param{backlog} era corrispondente al massimo valore della somma del numero di voci possibili per ciascuna delle due code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di 1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari @@ -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,13 +1189,13 @@ 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. Infine è da chiarire (si legga la pagina di manuale) che, come per -\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g +\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un \ctyp{int *} come prima dello standard perché tutte le implementazioni dei socket BSD fanno questa assunzione. @@ -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} @@ -1460,7 +1467,7 @@ programma. Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione \func{listen} che dice al kernel di accettare connessioni per il socket che -abbiamo creato; la funzione indica inoltre, con il secondo parametro, il +abbiamo creato; la funzione indica inoltre, con il secondo argomento, il numero massimo di connessioni che il kernel accetterà di mettere in coda per il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37}) un messaggio, e si esce (\texttt{\small 38}) immediatamente. @@ -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. @@ -2434,13 +2442,13 @@ di RST, contraddistinto dalla lettera \texttt{R}, che causa la conclusione definitiva della connessione anche nel client, dove non comparirà più nell'output di \cmd{netstat}. -Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più avanti -in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket è -una operazione lecita, per cui la nostra scrittura avrà comunque successo +Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più +avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket +è una operazione lecita, per cui la nostra scrittura avrà comunque successo (come si può constatare lanciando usando \cmd{strace}\footnote{il comando - \cmd{strace} è un comando di debug molto utile che prende come parametro un + \cmd{strace} è un comando di debug molto utile che prende come argomento un altro comando e ne stampa a video tutte le invocazioni di una system call, - coi relativi parametri e valori di ritorno, per cui usandolo in questo + coi relativi argomenti e valori di ritorno, per cui usandolo in questo contesto potremo verificare che effettivamente la \func{write} ha scritto la riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro programma non ha a questo punto alcun modo di sapere che dall'altra parte non @@ -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