\begin{figure}[htb]
\centering
- \includegraphics[width=10cm]{img/three_way_handshake.eps}
+ \includegraphics[width=10cm]{img/three_way_handshake}
\caption{Il \textit{three way handshake} del TCP}
\label{fig:TCPel_TWH}
\end{figure}
\textsl{finestra annunciata} (\textit{advertized window}) con la quale
ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
memoria per i dati. Questo è un numero a 16 bit dell'header, che così può
- indicare un massimo di 65535 bytes (anche se Linux usa come massimo 32767
+ indicare un massimo di 65535 byte (anche se Linux usa come massimo 32767
per evitare problemi con alcuni stack bacati che usano l'aritmetica con
segno per implementare lo stack TCP); ma alcuni tipi di connessione come
quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi
\begin{figure}[htb]
\centering
- \includegraphics[width=10cm]{img/tcp_close.eps}
+ \includegraphics[width=10cm]{img/tcp_close}
\caption{La chiusura di una connessione TCP}
\label{fig:TCPel_close}
\end{figure}
eseguire la chiusura passiva a quello che sta eseguendo la chiusura attiva.
Nella sequenza indicata i dati verrebbero persi, dato che si è chiuso il
socket dal lato che esegue la chiusura attiva; esistono tuttavia situazioni in
-cui si vuole poter sfuttare questa possibilità, usando una procedura che è
+cui si vuole poter sfruttare questa possibilità, usando una procedura che è
chiamata \textit{half-close}; torneremo su questo aspetto e su come
utilizzarlo più avanti, quando parleremo della funzione \func{shutdown}.
\begin{figure}[htb]
\centering
- \includegraphics[width=9cm]{img/tcp_connection.eps}
+ \includegraphics[width=9cm]{img/tcp_connection}
\caption{Schema dello scambio di pacchetti per un esempio di connessione}
\label{fig:TPCel_conn_example}
\end{figure}
La connessione viene iniziata dal client che annuncia un MSS di 1460 (un
-valore tipico per IPv4 su ethernet) con Linux, il server risponde con lo
+valore tipico per IPv4 su Ethernet) con Linux, il server risponde con lo
stesso valore (ma potrebbe essere anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
-1460 bytes annunciati dal server), quest'ultimo riceve la richiesta e
+1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
restituisce una risposta (che di nuovo supponiamo stare in un singolo
segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
risposta, questo viene chiamato \textit{piggybacking} ed avviene tutte le
\begin{figure}[!htb]
\centering
- \includegraphics[width=10cm]{img/port_alloc.eps}
+ \includegraphics[width=10cm]{img/port_alloc}
\caption{Allocazione dei numeri di porta}
\label{fig:TCPel_port_alloc}
\end{figure}
operazione.
\item \macro{EAGAIN} o \macro{EWOULDBLOCK} il socket è stato settato come
non bloccante, e non ci sono connessioni in attesa di essere accettate.
- \item \macro{EFAULT} l'argomento \var{addr} .
- \item \macro{EPERM} Firewall rules forbid connection.
-
- \item \macro{ENOBUFS, ENOMEM} Not enough free memory. This often means
- that the memory allocation is limited by the socket buffer limits, not by
- the system memory.
-
- Inoltre possono essere restituiti gli errori di rete relativi al nuovo
- socket come: \macro{EMFILE}, \macro{EINVAL}, \macro{ENOSR},
- \macro{ENOBUFS}, \macro{EPERM}, \macro{ECONNABORTED},
- \macro{ESOCKTNOSUPPORT}, \macro{EPROTONOSUPPORT}, \macro{ETIMEDOUT},
- \macro{ERESTARTSYS}.
-
+ \item \macro{EPERM} Le regole del firewall non consentono la connessione.
+ \item \macro{ENOBUFS, ENOMEM} . Questo spesso significa che l'allocazione
+ della memoria è limitata dai limiti sui buffer dei socket, non dalla
+ memoria di sistema.
\end{errlist}
+ Inoltre possono essere restituiti gli errori di rete relativi al nuovo
+ socket come: \macro{EMFILE}, \macro{EINVAL}, \macro{ENOSR}, \macro{ENOBUFS},
+ \macro{EFAULT}, \macro{EPERM}, \macro{ECONNABORTED},
+ \macro{ESOCKTNOSUPPORT}, \macro{EPROTONOSUPPORT}, \macro{ETIMEDOUT},
+ \macro{ERESTARTSYS}.
\end{prototype}
La funzione può essere usata solo con socket che supportino la connessione
esplicita della connessione, (attualmente in Linux solo DECnet ha questo
comportamento), la funzione opera solo l'estrazione dalla coda delle
connessioni, la conferma della connessione viene fatta implicitamente dalla
-prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto
-della connessione viene fatto con la funzione \func{close}.
+prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto della
+connessione viene fatto con la funzione \func{close}.
È da chiarire che Linux presenta un comportamento diverso nella gestione degli
errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
l'indirizzo del client da cui proviene la connessione. Prima della chiamata
\var{addrlen} deve essere inizializzato alle dimensioni della struttura il
cui indirizzo è passato come argomento in \var{cliaddr}, al ritorno della
-funzione \var{addrlen} conterrà il numero di bytes scritti dentro
+funzione \var{addrlen} conterrà il numero di byte scritti dentro
\var{cliaddr}. Se questa informazione non interessa basterà inizializzare a
\macro{NULL} detti puntatori.
questo avviene quando il server invece di far gestire la connessione
direttamente a un processo figlio, come nell'esempio precedente, lancia un
opportuno programma per ciascuna connessione usando \func{exec} (questa ad
-esempio è la modailità con cui opera il \textsl{super-server} \cmd{inetd}
+esempio è la modalità con cui opera il \textsl{super-server} \cmd{inetd}
che gestisce tutta una serie di servizi lanciando per ogni connessione
l'opportuno server).
projects / gapil.git / blobdiff