X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=tcpsock.tex;h=f7a706b903904c87e7f369710972782210d69bab;hb=ed58e97aab357cc8050633248dd092d74980b867;hp=78a6ce446664057d26eecd33fc6de8ea8f8fc65f;hpb=847a6cd39fe3d885ececc0658dfa5a4862534627;p=gapil.git diff --git a/tcpsock.tex b/tcpsock.tex index 78a6ce4..f7a706b 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -1,6 +1,6 @@ %% tcpsock.tex %% -%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2006 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", @@ -38,7 +38,7 @@ significato di alcuni dei vari \textsl{stati} ad essa associati. \subsection{La creazione della connessione: il \textit{three way handshake}} \label{sec:TCP_conn_cre} -\index{\textit{three~way~handshake}|(} +\itindbeg{three~way~handshake} Il processo che porta a creare una connessione TCP è chiamato \textit{three way handshake}; la successione tipica degli eventi (e dei \textsl{segmenti}\footnote{Si ricordi che il segmento è l'unità elementare di @@ -118,7 +118,8 @@ aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN. -\index{\textit{three~way~handshake}|)} + +\itindend{three~way~handshake} \subsection{Le opzioni TCP.} @@ -136,7 +137,8 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: connessione corrente. È possibile leggere e scrivere questo valore attraverso l'opzione del socket \const{TCP\_MAXSEG}. -\item \textit{window scale option}, %come spiegato in sez.~\ref{sec:tcp_protocol} +\item \textit{window scale + option}, %come spiegato in sez.~\ref{sec:tcp_protocol} il protocollo TCP implementa il controllo di flusso attraverso una \textsl{finestra annunciata} (\textit{advertized window}) con la quale ciascun capo della comunicazione dichiara quanto spazio disponibile ha in @@ -392,7 +394,7 @@ una connessione fra due router si interrompa. In questo caso i protocolli di instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine dei minuti) prima di trovare e stabilire un percorso alternativo per i pacchetti. Nel frattempo possono accadere casi in cui un router manda i -pacchetti verso un'altro e quest'ultimo li rispedisce indietro, o li manda ad +pacchetti verso un altro e quest'ultimo li rispedisce indietro, o li manda ad un terzo router che li rispedisce al primo, si creano cioè dei circoli (i cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti. @@ -620,17 +622,17 @@ tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED tcp 0 0 195.110.112.152:22 192.84.146.100:21101 ESTABLISHED \end{verbatim} cioè il client effettuerà la connessione usando un'altra porta effimera: con -questa sarà aperta la connessione, ed il server creerà un'altro processo +questa sarà aperta la connessione, ed il server creerà un altro processo figlio per gestirla. Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server concorrente, non può suddividere i pacchetti solo sulla base della porta di destinazione, ma deve usare tutta l'informazione contenuta nella socket pair, compresa la porta dell'indirizzo remoto. E se andassimo a vedere quali sono i -processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}.} a -cui fanno riferimento i vari socket vedremmo che i pacchetti che arrivano -dalla porta remota 21100 vanno al primo figlio e quelli che arrivano alla -porta 21101 al secondo. +processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}, o + usando l'opzione \texttt{-p}.} a cui fanno riferimento i vari socket +vedremmo che i pacchetti che arrivano dalla porta remota 21100 vanno al primo +figlio e quelli che arrivano alla porta 21101 al secondo. \section{Le funzioni di base per la gestione dei socket} @@ -716,7 +718,7 @@ Si noti che si \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è inutile. Si tenga presente comunque che tutte le costanti \val{INADDR\_} (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo -l'\textit{endianess}\index{\textit{endianess}} della macchina, ed anche se +l'\textit{endianess}\itindex{endianess} della macchina, ed anche se esse possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare sempre la funzione \func{htonl}. @@ -729,7 +731,8 @@ buona norma usare sempre la funzione \func{htonl}. \hline \hline \const{INADDR\_ANY} & Indirizzo generico (\texttt{0.0.0.0})\\ - \const{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\ + \const{INADDR\_BROADCAST}& Indirizzo di \itindex{broadcast} + \textit{broadcast}.\\ \const{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback} (\texttt{127.0.0.1}).\\ \const{INADDR\_NONE} & Indirizzo errato.\\ @@ -746,10 +749,10 @@ con una struttura, perch costante come operando a destra in una assegnazione. Per questo motivo nell'header \file{netinet/in.h} è definita una variabile -\const{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal +\macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in -maniera analoga si può utilizzare la variabile \const{in6addr\_loopback} per +maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}. @@ -765,8 +768,8 @@ connessione con un server TCP,\footnote{di nuovo la funzione limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati 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: + TCP il \itindex{three~way~handshake}\textit{three way handshake}) della + connessione.} il prototipo della funzione è il seguente: \begin{prototype}{sys/socket.h} {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t addrlen)} @@ -791,8 +794,9 @@ connessione con un server TCP,\footnote{di nuovo la funzione \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi corretta nel relativo campo. \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una - connessione ad un indirizzo broadcast senza che il socket fosse stato - abilitato per il broadcast. + connessione ad un indirizzo \itindex{broadcast} \textit{broadcast} senza + che il socket fosse stato abilitato per il \itindex{broadcast} + \textit{broadcast}. \end{errlist} altri errori possibili sono: \errval{EFAULT}, \errval{EBADF}, \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.} @@ -809,7 +813,7 @@ nell'esempio sez.~\ref{sec:TCP_daytime_client}, usando le funzioni illustrate in sez.~\ref{sec:sock_addr_func}. Nel caso di socket TCP la funzione \func{connect} avvia il -\index{\textit{three~way~handshake}}\textit{three way handshake}, e ritorna +\itindex{three~way~handshake}\textit{three way handshake}, e ritorna solo quando la connessione è stabilita o si è verificato un errore. Le possibili cause di errore sono molteplici (ed i relativi codici riportati sopra), quelle che però dipendono dalla situazione della rete e non da errori @@ -817,7 +821,7 @@ o problemi nella chiamata della funzione sono le seguenti: \begin{enumerate} \item Il client non riceve risposta al SYN: l'errore restituito è \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata - di \func{connect}, un'altro dopo 6 secondi, un terzo dopo 24 secondi, se + di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24 secondi, se dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero di volte che può essere stabilito dall'utente sia con una opportuna @@ -825,10 +829,7 @@ o problemi nella chiamata della funzione sono le seguenti: voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo circa 180 secondi. -% -% Le informazioni su tutte le opzioni impostabili via /proc stanno in -% Linux/Documentation/networking/ip-sysctl.txt -% + \item Il client riceve come risposta al SYN un RST significa che non c'è nessun programma in ascolto per la connessione sulla porta specificata (il che vuol dire probabilmente che o si è sbagliato il numero della porta o che @@ -908,13 +909,14 @@ infatti vengono mantenute due code: \begin{enumerate} \item La coda delle connessioni incomplete (\textit{incomplete connection queue} che contiene un riferimento per ciascun socket per il quale è - arrivato un SYN ma il \index{\textit{three~way~handshake}}\textit{three way + arrivato un SYN ma il \itindex{three~way~handshake}\textit{three way handshake} non si è ancora concluso. Questi socket sono tutti nello stato \texttt{SYN\_RECV}. \item La coda delle connessioni complete (\textit{complete connection queue} - che contiene un ingresso per ciascun socket per il quale il \textit{three - way handshake} è stato completato ma ancora \func{accept} non è ritornata. - Questi socket sono tutti nello stato \texttt{ESTABLISHED}. + che contiene un ingresso per ciascun socket per il quale il + \itindex{three~way~handshake} \textit{three way handshake} è stato + completato ma ancora \func{accept} non è ritornata. Questi socket sono + tutti nello stato \texttt{ESTABLISHED}. \end{enumerate} Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}: @@ -922,7 +924,7 @@ quando arriva un SYN da un client il server crea una nuova voce nella coda delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad un timeout. Nel caso di completamento del -\index{\textit{three~way~handshake}}\textit{three way handshake} la voce viene +\itindex{three~way~handshake} \textit{three way handshake} la voce viene spostata nella coda delle connessioni complete. Quando il processo chiama la funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept}) la prima voce nella coda delle connessioni complete è passata al programma, o, se la coda è @@ -962,7 +964,9 @@ protezione dei syncookies per attivare usando \file{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore viene ignorato e non esiste più un valore massimo. In ogni caso in Linux il valore di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se è -superiore a detta costante (che di default vale 128). +superiore a detta costante (che di default vale 128).\footnote{il valore di + questa costante può essere controllato con un altro parametro di + \func{sysctl}, vedi sez.~\ref{sec:sock_ioctl_IP}.} La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi kernel non supportavano neanche valori superiori, ma la situazione corrente è @@ -979,7 +983,7 @@ che il compito principale della coda sia quello di gestire il caso in cui il server è occupato fra chiamate successive alla \func{accept} (per cui la coda più occupata sarebbe quella delle connessioni completate), ma piuttosto quello di gestire la presenza di un gran numero di SYN in attesa di concludere il -\textit{three way handshake}\index{\textit{three~way~handshake}}. +\itindex{three~way~handshake} \textit{three way handshake}. Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la @@ -997,10 +1001,10 @@ trasparente dal protocollo TCP. \label{sec:TCP_func_accept} 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 \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} e - \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su +una volta che sia stato completato il \itindex{three~way~handshake} +\textit{three way handshake},\footnote{la funzione è comunque generica ed è + utilizzabile 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: @@ -1464,13 +1468,14 @@ delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small 31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il 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 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. +Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{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 +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. La chiamata a \func{listen} completa la preparazione del socket per l'ascolto (che viene chiamato anche \textit{listening descriptor}) a questo punto si può @@ -1792,7 +1797,7 @@ processo ad un gruppo senza privilegi,\footnote{si 27--30}) l'operazione usando \func{setuid} per cambiare anche l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste due operazioni è importante, infatti solo avendo i privilegi di - amministratore si può cambiare il gruppo di un processo ad un'altro di cui + amministratore si può cambiare il gruppo di un processo ad un altro di cui non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una successiva chiamata a \func{setgid}. Inoltre si ricordi (si riveda quanto esposto in sez.~\ref{sec:proc_perms}) che usando queste due funzioni il @@ -1911,12 +1916,13 @@ connessioni da qualunque indirizzo e da qualunque porta e su qualunque interfaccia locale. A questo punto si può lanciare il client, esso chiamerà \func{socket} e -\func{connect}; una volta completato il \textit{three way handshake} la -connessione è stabilita; la \func{connect} ritornerà nel client\footnote{si - noti che è sempre la \func{connect} del client a ritornare per prima, in - quanto questo avviene alla ricezione del secondo segmento (l'ACK del server) - del \textit{three way handshake}, la \func{accept} del server ritorna solo - dopo un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene +\func{connect}; una volta completato il \itindex{three~way~handshake} +\textit{three way handshake} la connessione è stabilita; la \func{connect} +ritornerà nel client\footnote{si noti che è sempre la \func{connect} del + client a ritornare per prima, in quanto questo avviene alla ricezione del + secondo segmento (l'ACK del server) del \itindex{three~way~handshake} + \textit{three way handshake}, la \func{accept} del server ritorna solo dopo + un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene ricevuto.} e la \func{accept} nel server, ed usando di nuovo \cmd{netstat} otterremmo che: \begin{verbatim} @@ -2079,7 +2085,7 @@ installeremo il gestore usando quest'ultima. \includecodesample{listati/SignalRestart.c} \end{minipage} \normalsize - \caption{La funzione \funcd{SignalRestart}, che installa un gestore di + \caption{La funzione \func{SignalRestart}, che installa un gestore di segnali in semantica BSD per il riavvio automatico delle system call interrotte.} \label{fig:sig_SignalRestart_code} @@ -2157,11 +2163,11 @@ fig.~\ref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima dell'entrata nel ciclo principale è stata quella di aver introdotto, subito dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile -\var{waiting}, che viene inizializzata, con l'opzione \code{-w Nsec}, al +\var{waiting}, che viene inizializzata, con l'opzione \texttt{-w Nsec}, al numero di secondi da aspettare (il valore preimpostato è nullo). Si è potuto lasciare inalterata tutta la sezione di creazione del socket -perché nel server l'unica chiamata ad una system call critica, che può essere +perché nel server l'unica chiamata ad una system call lenta, che può essere interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è l'unica funzione che può mettere il processo padre in stato di sleep nel periodo in cui un figlio può terminare; si noti infatti come le altre @@ -2262,10 +2268,10 @@ Bench con dei server molto occupati. In tal caso, con una struttura del server simile a quella del nostro esempio, in cui la gestione delle singole connessioni è demandata a processi figli, può accadere che il \textit{three - way handshake}\index{\textit{three~way~handshake}} venga completato e la -relativa connessione abortita subito dopo, prima che il padre, per via del -carico della macchina, abbia fatto in tempo ad eseguire la chiamata ad -\func{accept}. Di nuovo si ha una situazione analoga a quella illustrata in + way handshake} \itindex{three~way~handshake} venga completato e la relativa +connessione abortita subito dopo, prima che il padre, per via del carico della +macchina, abbia fatto in tempo ad eseguire la chiamata ad \func{accept}. Di +nuovo si ha una situazione analoga a quella illustrata in fig.~\ref{fig:TCP_early_abort}, in cui la connessione viene stabilita, ma subito dopo si ha una condizione di errore che la chiude prima che essa sia stata accettata dal programma. @@ -2372,33 +2378,33 @@ anarres.echo > gont.34559: R 511689732:511689732(0) win 0 \end{verbatim} Le prime tre righe vengono prodotte al momento in cui lanciamo il nostro -client, e corrispondono ai tre pacchetti del -\index{\textit{three~way~handshake}}\textit{three way handshake}. L'output -del comando riporta anche i numeri di sequenza iniziali, mentre la lettera -\texttt{S} indica che per quel pacchetto si aveva il SYN flag attivo. Si noti -come a partire dal secondo pacchetto sia sempre attivo il campo \texttt{ack}, -seguito dal numero di sequenza per il quale si da il ricevuto; quest'ultimo, a -partire dal terzo pacchetto, viene espresso in forma relativa per maggiore -compattezza. Il campo \texttt{win} in ogni riga indica la \textit{advertising - window} di cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può -verificare dall'output del comando come venga appunto realizzata la sequenza -di pacchetti descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal -client un primo pacchetto con il SYN che inizia la connessione, a cui il -server risponde dando il ricevuto con un secondo pacchetto, che a sua volta -porta un SYN, cui il client risponde con un il terzo pacchetto di ricevuto. +client, e corrispondono ai tre pacchetti del \itindex{three~way~handshake} +\textit{three way handshake}. L'output del comando riporta anche i numeri di +sequenza iniziali, mentre la lettera \texttt{S} indica che per quel pacchetto +si aveva il SYN flag attivo. Si noti come a partire dal secondo pacchetto sia +sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il +quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene +espresso in forma relativa per maggiore compattezza. Il campo \texttt{win} in +ogni riga indica la \textit{advertising window} di cui parlavamo in +sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare dall'output del comando +come venga appunto realizzata la sequenza di pacchetti descritta in +sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un primo pacchetto +con il SYN che inizia la connessione, a cui il server risponde dando il +ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui il client +risponde con un il terzo pacchetto di ricevuto. Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe -del \textit{three way handshake}\index{\textit{three~way~handshake}} non -avremo nulla fin tanto che non scriveremo una prima riga sul client; al -momento in cui facciamo questo si genera una sequenza di altri quattro -pacchetti. Il primo, dal client al server, contraddistinto da una lettera -\texttt{P} che significa che il flag PSH è impostato, contiene la nostra riga -(che è appunto di 11 caratteri), e ad esso il server risponde immediatamente -con un pacchetto vuoto di ricevuto. Poi tocca al server riscrivere indietro -quanto gli è stato inviato, per cui sarà lui a mandare indietro un terzo -pacchetto con lo stesso contenuto appena ricevuto, e a sua volta riceverà dal -client un ACK nel quarto pacchetto. Questo causerà la ricezione dell'eco nel -client che lo stamperà a video. +del \textit{three way handshake} \itindex{three~way~handshake} non avremo nulla +fin tanto che non scriveremo una prima riga sul client; al momento in cui +facciamo questo si genera una sequenza di altri quattro pacchetti. Il primo, +dal client al server, contraddistinto da una lettera \texttt{P} che significa +che il flag PSH è impostato, contiene la nostra riga (che è appunto di 11 +caratteri), e ad esso il server risponde immediatamente con un pacchetto vuoto +di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato +inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso +contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto +pacchetto. Questo causerà la ricezione dell'eco nel client che lo stamperà a +video. A questo punto noi procediamo ad interrompere l'esecuzione del server con un \texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui @@ -2589,7 +2595,7 @@ arp who-has anarres tell gont In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso di prima. Solo che stavolta, non appena inviata la seconda riga, il programma -si bloccherà nella successiva chiamata a \func{read}, non ottendo nessuna +si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna risposta. Quello che succede è che nel frattempo il kernel provvede, come richiesto dal protocollo TCP, a tentare la ritrasmissione della nostra riga un certo numero di volte, con tempi di attesa crescente fra un tentativo ed il @@ -2617,7 +2623,7 @@ Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP che si incarica di trovare le corrispondenze fra indirizzo IP e indirizzo hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo client e server sulla stessa rete, è scaduta la voce nella \textit{ARP - cache}\footnote{la \textit{ARP chache} è una tabella mantenuta internamente + cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente dal kernel che contiene tutte le corrispondenze fra indirizzi IP e indirizzi fisici, ottenute appunto attraverso il protocollo ARP; le voci della tabella hanno un tempo di vita limitato, passato il quale scadono e devono essere @@ -3122,8 +3128,9 @@ velocit una macchina remota occorre un certo tempo perché i pacchetti vi arrivino, vengano processati, e poi tornino indietro. Considerando trascurabile il tempo di processo, questo tempo è quello impiegato nella trasmissione via rete, che -viene detto RTT (dalla denominazione inglese \textit{Round Trip Time}) ed è -quello che viene stimato con l'uso del comando \cmd{ping}. +viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time} +\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando +\cmd{ping}. A questo punto, se torniamo al codice mostrato in fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti @@ -3531,7 +3538,7 @@ notificher di end-of-file (\texttt{\small 38--47}) si provvederà a chiudere (\texttt{\small 39}) anche il nostro capo del socket e a marcarlo (\texttt{\small 40}) nella struttura ad esso associata come inutilizzato. -Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventiale nuovo +Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro sul socket. @@ -3548,6 +3555,45 @@ ingresso. Si applicano comunque anche a questo server le considerazioni finali di sez.~\ref{sec:TCP_serv_select}. +% LocalWords: socket TCP client dell'I multiplexing stream three way handshake +% LocalWords: header stack kernel SYN ACK URG syncronize sez bind listen fig +% LocalWords: accept connect active acknowledge l'acknowledge nell'header MSS +% LocalWords: sequence number l'acknowledgement dell'header options l'header +% LocalWords: option MMS segment size MAXSEG window advertized Mbit sec nell' +% LocalWords: timestamp RFC long fat close of l'end l'ACK half shutdown CLOSED +% LocalWords: netstat SENT ESTABLISHED WAIT IPv Ethernet piggybacking UDP MSL +% LocalWords: l'overhead Stevens Lifetime router hop limit TTL to live RST SSH +% LocalWords: routing dell'MSL l'IP multitasking well known port ephemeral BSD +% LocalWords: ports dall' IANA Assigned Authority like glibc netinet IPPORT AF +% LocalWords: RESERVED USERRESERVED rsh rlogin pair socketpair Local Address +% LocalWords: Foreing DNS caching INADDR ANY multihoming loopback ssh fuser ip +% LocalWords: lsof SOCK sys int sockfd const struct sockaddr serv addr socklen +% LocalWords: addrlen errno EBADF descriptor EINVAL ENOTSOCK EACCES EADDRINUSE +% LocalWords: EADDRNOTAVAIL EFAULT ENOTDIR ENOENT ENOMEM ELOOP ENOSR EROFS RPC +% LocalWords: portmapper htonl tab endianess BROADCAST broadcast any extern fd +% LocalWords: ADRR INIT DGRAM SEQPACKET servaddr ECONNREFUSED ETIMEDOUT EAGAIN +% LocalWords: ENETUNREACH EINPROGRESS EALREADY EAFNOSUPPORT EPERM EISCONN proc +% LocalWords: sysctl filesystem syn retries reset ICMP backlog EOPNOTSUPP RECV +% LocalWords: connection queue dell'ACK flood spoofing syncookies SOMAXCONN CR +% LocalWords: RDM EWOULDBLOCK firewall ENOBUFS EINTR EMFILE ECONNABORTED NULL +% LocalWords: ESOCKTNOSUPPORT EPROTONOSUPPORT ERESTARTSYS connected listening +% LocalWords: DECnet read write NONBLOCK fcntl getsockname getpeername name ps +% LocalWords: namelen namlen ENOTCONN exec inetd POSIX daytime FullRead count +% LocalWords: BUF FullWrite system call INET perror htons inet pton ctime FTP +% LocalWords: fputs carriage return line feed superdemone daytimed sleep fork +% LocalWords: daemon cunc logging list conn sock exit snprintf ntop ntohs echo +% LocalWords: crash superserver L'RFC first ClientEcho stdin stdout fgets main +% LocalWords: MAXLINE initd echod ServEcho setgid short nogroup nobody setuid +% LocalWords: demonize PrintErr syslog wrapper log error root RTT EOF ctrl ack +% LocalWords: while SIGCHLD Signal RESTART sigaction SignalRestart SigHand win +% LocalWords: flags select recvfrom debug second compat waiting Nsec ENETDOWN +% LocalWords: EPROTO ENOPROTOOPT EHOSTDOWN ENONET EHOSTUNREACH LINGER tcpdump +% LocalWords: ECONNRESET advertising PSH SIGTERM strace SIGPIPE gets tcp ARP +% LocalWords: cache anarres destination unreachable l'I low watermark RCVLOWAT +% LocalWords: SNDLOWAT third fset maxfd fileno ISSET closed how SHUT RD WR eof +% LocalWords: RDWR fifo Trip ping fourth CLR sull'I SETSIZE nread break Denial +% LocalWords: Service poll POLLIN POLLRDNORM POLLPRI POLLRDBAND POLLOUT events +% LocalWords: POLLHUP POLLERR revents pollfd %%% Local Variables: %%% mode: latex