X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=tcpsock.tex;h=54b9e0a93c17decdb52a84be861b38f7817a5f28;hb=dd741fcfa876c0a4c26a72da0035b7cfea8202e2;hp=4898087646e57f583b76a82d8e95c7a6bbcf74e3;hpb=22e01eeebd2d386a8a992cba0fdaf2d73f5ff217;p=gapil.git

diff --git a/tcpsock.tex b/tcpsock.tex
index 4898087..54b9e0a 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",
@@ -913,9 +913,10 @@ infatti vengono mantenute due code:
     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}:
@@ -923,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
-\itindex{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 è
@@ -980,7 +981,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}\itindex{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
@@ -1465,13 +1466,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ò
@@ -1916,10 +1918,11 @@ A questo punto si pu
 \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 ricevuto.}  e la \func{accept} nel
-server, ed usando di nuovo \cmd{netstat} otterremmo che:
+  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}
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
@@ -2263,7 +2266,7 @@ 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}\itindex{three~way~handshake} venga completato e la relativa
+  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
@@ -2373,23 +2376,23 @@ 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
-\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.
+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}\itindex{three~way~handshake} non avremo nulla
+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
@@ -2590,7 +2593,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
@@ -2618,7 +2621,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
@@ -3123,8 +3126,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
@@ -3532,7 +3536,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.
@@ -3554,3 +3558,43 @@ di sez.~\ref{sec:TCP_serv_select}.
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
+
+% 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